Обобщение моделей данных в создании ИС

АВТОНОМНАЯНЕКОМЕРЧЕСКАЯ ОРГАНИЗАЦИЯ
ЕВРАЗИЙСКИЙОТКРЫТЫЙ ИНСТИТУТ
КоломенскийфилиалНАУЧНО-ИССЛЕДОВАТЕЛЬСКАЯРАБОТА
Обобщение моделей данных в создании ИС
 
Выполнили:
Студентки 4 курса группы 41-П
Хромова Валентина Сергеевна
ИНС № 0021-02014
Литвиненко Мария Николаевна
ИНС № 0021-01931
 
г. Коломна,2009 год

ОГЛАВЛЕНИЕ
Введение
Глава I. Классические модели данных
1.1 Иерархическая модель данных
1.2 Сетевая модель данных
1.3 Реляционная модель данных
Глава II. Неклассические модели данных
2.1      Постреляционнаямодель данных
2.2      Многомернаямодель данных
2.3      Объектно-ориентированнаямодель данных
Глава III. Сравнение классических моделей данных
3.1 Достоинства и недостаткиреляционной модели
3.3 Достоинства и недостатки сетевоймодели
3.2 Достоинства и недостатки иерархическоймодели
ЗаключениеСписок использованнойлитературы
Приложение

Введение
Современная жизнь немыслимабез эффективного управления. Важной категорией являются системы обработки информации,от которых во многом зависит эффективность работы любого предприятия или учреждения.Такая система должна:
 - обеспечивать получениеобщих и/или детализированных отчетов по
 итогам работы;
 - позволять легко определятьтенденции изменения важнейших
 показателей;
 - обеспечивать получениеинформации, критической по времени, без
 существенных задержек;
 - выполнять точный иполный анализ данных.
Современные системы управлениябазами данных (СУБД) в основном являются приложениями Windows, так как даннаясреда позволяет более полно использовать возможности персональной ЭВМ, нежели средаDOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переходк среде Windows, где разработчик программного обеспечения может в меньшей степенизаботиться о распределении ресурсов, но также сделал программное обеспечение ПКв целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ. Срединаиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемыев приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современнойСУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную областьприменения и возможности, любое приложение способно работать со многими форматамипредставления данных, осуществлять экспорт и импорт данных благодаря наличиюбольшого числа конвертеров. Общепринятыми, также, являются технологии, позволяющиеиспользовать возможности других приложений, например, текстовых процессоров,пакетов построения графиков и т.п., и встроенные версии языков высокого уровня(чаще – диалекты SQL и/или VBA) и средства визуального программирования интерфейсовразрабатываемых приложений. Поэтому уже не имеет существенного значения накаком языке и на основе какого пакета написано конкретное приложение, и какой форматданных в нем используется. Более того, стандартом «де-факто» стала «быстраяразработка приложений» или RAD (от английского Rapid Application Development),основанная на широко декларируемом в литературе «открытом подходе», то есть необходимостьи возможность использования различных прикладных программ и технологий для разработкиболее гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими»СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++,которые позволяют быстро создавать необходимые компоненты приложений, критичныепо скорости работы, которые трудно, а иногда невозможно разработать средствами«классических» СУБД. Современный подход к управлению базами данныхподразумевает также широкое использование технологии «клиент-сервер».
Таким образом, на сегодняшнийдень разработчик не связан рамками какого-либо конкретного пакета, а в зависимостиот поставленной задачи может использовать самые разные приложения. Поэтому, болееважным представляется общее направление развития СУБД и других средств разработкиприложений в настоящее время.
Актуальность темы определяется тем, что цель любойинформационной системы – обработка данных об объектах реального мира. Основные идеисовременной информационной технологии базируются на концепции баз данных.
Хранимые в базе данныеимеют определенную логическую структуру — иными словами, описываются некотороймоделью представления данных (моделью данных), поддерживаемой СУБД.
Объектом исследования являются следующие классическихмодели данных.
1.   Иерархическая;
2.   Сетевая;
3.   Реляционная;
Кроме того, в последниегоды появились и стали более активно внедряться на практике следующие моделиданных:
1.   постреляционная;
2.   многомерная;
3.   объектно-ориентированная.
Разрабатываются такжевсевозможные системы, основанные на других моделях данных, расширяющихизвестные модели. B их числе можно назвать объектно-реляционные,дедуктивно-объектно-ориентированные, семантические, концептуальные иориентированные модели. Некоторые из этих моделей служат для интеграции базданных, баз знаний и языков программирования.
B некоторых СУБДподдерживаются одновременно несколько моделей данных. Например, в системеИНТЕРБАЗА для приложений применяется сетевой язык манипулирования данными, а впользовательском интерфейсе реализованы языки SQL и QBE.
Цель работы — описать структуру каждой моделиданных, недостатки и достоинства, привести примеры использования в практикекаждой модели.
Задачи исследования:
1.        Изучитьиерархическую модель данных;
2.        Изучитьсетевую модель данных;
3.        Изучитьреляционную модель данных;
4.        Изучитьпостреляционную модель данных;
5.        Изучитьмногомерную модель данных;
6.        Изучитьобъектно-ориентированную модель данных;
7.        Сравнитьклассические модели данных.
Теоретическая основаисследования –структуры моделей, представление связей, недостатки и достоинства, каждоймодели. Использованы работы авторов: А.И. Мишенин, И.Г. Семакин, Е.К. Хеннер,Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов, А.Д. Хомоненко, В.М. Цыганков, М.Г.Мальцев

Глава I. Классические модели данных
 
1.1 Иерархическаямодель данных
В иерархической модели связи междуданными можно описать с помощью упорядоченного графа (или дерева). Упрощеннопредставление связей между данными в иерархической модели показано на рис.1.(см. Приложение рис.1.) Для описания структуры (схемы) иерархической БД нанекотором языке программирования используется тип данных «дерево». Тип «дерево»схож с типами данных «структура» языков программирования ПЛ/1 и C и «запись»языка Паскаль. В них допускается вложенность типов, каждый из которых находитсяна некотором уровне. Тип «дерево» является составным. Он включает в себя подтипы(«поддеревья»), каждый из которых, в свою очередь, является типом «дерево».Каждый из типов «дерево» состоит из одного «корневого» типа и упорядоченногонабора (возможно, пустого) подчиненных типов. Каждый из элементарных типов,включённых в тип «дерево», является простым или составным типом «запись».Простая «запись» состоит из одного типа, например числового, а составная«запись» объединяет некоторую совокупность типов, например, целое, строкусимволов и указатель (ссылку). Пример типа «дерево» как совокупности типовпоказан на рис.2. (см. Приложение рис.2.)
Корневым называется тип, который имеетподчиненные типы и сам не является подтипом. Подчинённый тип (подтип)является потомком по отношению к типу, который выступает для него в ролипредка (родителя). Потомки одного и того же типа являются близнецами поотношению друг к другу.
B целом тип «дерево» представляетсобой иерархически организованный набор типов «запись».
Иерархическая БД, представляет собойупорядоченную совокупность экземпляров данных типа «дерево» (деревьев),содержащих экземпляры типа «запись» (записи). Часто отношения родства междутипами переносят на отношения между самими записями. Поля записей хранятсобственно числовые или символьные значения, составляющие основное содержание БД.Обход всех элементов иерархической БД обычно производится сверху вниз и слеванаправо.
В иерархических СУБД можетиспользоваться терминология, отличающаяся от приведенной. Так, в системе IMSпонятию «запись» соответствует термин «сегмент», а под «записью БД» понимаетсявся совокупность записей, относящаяся к одному экземпляру типа «дерево».
Данные в базе с приведенной схемой(рис.2.) могут выглядеть, например, как показано на рис.3. (см. Приложение рис.3.)
Для организации физическогоразмещения иерархических данных в памяти ЭВМ могут использоваться следующиегруппы методов:
1.        представлениелинейным списком с последовательным распределением памяти (адресная арифметика,левосписковые структуры);
2.        представлениесвязными линейными списками (методы, использующие указатели и справочники).
К основным операциям манипулированияиерархически организованными данными относятся следующие:
1.        поиск указанногоэкземпляра БД;
2.        переход от одногодерева к другому;
3.        переход от однойзаписи к другой внутри;
4.        вставка новойзаписи в указанную позицию;
5.        удаление текущейзаписи и т. д.
Bсоответствии с определением типа «дерево», можно заключить, что между предкамии потомками автоматически поддерживается контроль целостности связей. Основноеправило контроля целостности формулируется следующим образом: потомок не можетсуществовать без родителя, а у некоторых родителей может не быть потомков. Механизмы поддержания целостностисвязей между записями различных деревьев отсутствуют.
K достоинствамиерархической модели данных относятся эффективное использование памяти ЭВМи неплохие показатели времени выполнения основных операций над данными.Иерархическая модель данных удобна для работы с иерархически упорядоченнойинформацией. Недостатком иерархической модели является ее громоздкостьдля обработки информации с достаточно сложными логическими связями, а такжесложность понимания для обычного пользователя. На иерархической модели данныхосновано сравнительно ограниченное количество СУБД, в числе которых можно назвать зарубежныесистемы IMS, PC/Focus, Теаm-Up и Data Еdgе, а также отечественные системы Ока,ИНЭС и МИРИС.
 
1.2 Сетевая модельданных
Сетевая модель данных позволяетотображать разнообразные взаимосвязи элементов данных в виде произвольногографа, обобщая тем самым иерархическую модель данных (рис. 4.). Наиболее полноконцепция сетевых БД впервые была изложена в Предложениях группы КОДАСИЛ(KODASYL). (см. Приложение рис.4.) Для описания схемы сетевой БД используетсядве группы типов: «запись» и «связь». Тип «связь» определяется для двух типов«запись»: предка и потомка. Переменная типа «связь» являются экземплярамисвязей. Сетевая БД состоит из набора записей и набора соответствующих связей.На формирование связи особых ограничений не накладывается. Если в иерархическихструктурах запись-потомок могла иметь только одну запись-предка, то в сетевоймодели данных запись-потомок может иметь произвольное число записей-предков(сводных родителей). Пример схемы простейшей сетевой БД показан на рис.5. Типысвязей здесь обозначены надписями на соединяющих типы записей линиях. (см.Приложение рис.5.) B различных СУБД сетевого типа для обозначения одинаковых посути понятий зачастую используются различные термины. Например, такие какэлементы и агрегаты данных, записи, наборы, области и т. д.
Физическое размещение данных в базахсетевого типа может быть организовано практически теми же методами, что и виерархических базах данных.
K числу важнейших операцийманипулирования данными баз сетевого типа можно отнести следующие:
·    поиск записи вБД;
·    переход от предкак первому потомку;
·    переход отпотомка к предку;
·    создание новойзаписи;
·    удаление текущейзаписи;
·    обновлениетекущей записи;
·    включение записив связь;
·    исключение записииз связи;
·    изменение связейи т. д.
Достоинством сетевой модели данныхявляется возможность эффективной реализации по показателям затрат памяти иоперативности. B сравнении с иерархической моделью сетевая модель предоставляетбольшие возможности в смысле допустимости образования произвольных связей.
Недостатком сетевой модели данных является высокая сложность ижесткость схемы БД, построенной на ее основе, а также сложность для понимания ивыполнения обработки информации в БД обычным пользователем. Кроме того, всетевой модели данных ослаблен контроль целостности связей вследствиедопустимости установления произвольных связен между записями.
Системы на основе сетевой модели неполучили широкого распространения на практике. Наиболее известными сетевымиСУБД являются следующие: IDMS, db_VistaIII, СЕТЬ, СЕТОР и КОМПАС.
1.3 Реляционная модельданных
Реляционная модель данных предложенасотрудником фирмы IBM Эдгаром Коддоми основывается на понятии отношение (relation).
Отношение представляет собоймножество элементов, называемых кортежами. Подробно теоретическая основареляционной модели данных рассматривается на следующем разделе. Нагляднойформой представления отношения является привычная для человеческого восприятиядвумерная таблица.
Таблица имеет строки (записи) истолбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоитиз полей. Строкам таблицы соответствуют кортежи, а столбцам — атрибутыотношения.
C помощью одной таблицы удобноописывать простейший вид связей между данными, а именно деление одного объекта(явления, сущности, системы и проч.), информация о котором хранится в таблице,на множество подобъектов, каждому из которых соответствует строка или записьтаблицы. При этом каждый из подобъектов имеет одинаковую структуру илисвойства, описываемые соответствующими значениями полей записей. Например,таблица может содержать сведения о группе обучаемых, о каждом из которыхизвестны следующие характеристики: фамилия, имя и отчество, пол, возраст иобразование. Поскольку в рамках одной таблицы не удается описать более сложныелогические структуры данных из предметной области, применяют связывание таблиц.
Физическое размещение данных вреляционных базах на внешних носителях легко осуществляется с помощью обычныхфайлов.
Достоинство реляционной модели данных заключается в простоте, понятности иудобстве физической реализации на ЭВМ. Именно простота и понятность дляпользователя явились основной причиной их широкого использования. Проблемы жеэффективности обработки данных этого типа оказались технически вполнеразрешимыми.
Основными недостатками реляционноймодели являются следующие: отсутствие стандартных средств идентификацииотдельных записей и сложность описания иерархических и сетевых связей.
Примерами зарубежных реляционных СУБДдля ПЭВМ являются следующие: DBaseIII Plus и dBase IY (фирма Ashton-Tate), DB2(IBM), R:BASE (Microrim), FoxFro ранних версий и EoxBase (Fox Software), Раrаdох и dBASE for Windows (Borland),FoxFro более поздних версий, Visual FoxFro и Access (Microsoft), Clarion(Clarion Software), Ingres (ASK Computer Systems) и Oracle (Oracle).
К отечественным СУБД реляционноготипа относятся системы: ПАЛЬМА (ИК АН УССР), а также система HyTech (МИФИ).
Заметим, что последние версииреляционных СУБД имеют некоторые свойства объектно-ориентированных систем.Такие СУБД часто называют объектно-реляционными. Примером такой системы можносчитать продукты Oracle 8.х. Системы предыдущих версий вплоть до Oracle 7.хсчитаются «чисто» реляционными.

Глава II. Неклассические модели данных
 
2.1 Постреляционнаямодель данных
 
Классическая реляционная модельпредполагает неделимость данных, хранящихся в полях записей таблиц. Этоозначает, что информация в таблице представляется в первой нормальной форме.Существует ряд случаен, когда это ограничение мешает эффективной реализацииприложений.
Постреляционная модель данных представляет собойрасширенную реляционную модель, снимающую ограничение неделимости данных,хранящихся в записях таблиц. Постреляционная модель данных допускаетмногозначные поля — поля, значения которых состоят из подзначений. Наборзначений многозначных полей считается самостоятельной таблицей, встроенной восновную таблицу.
На рис.6 на примере информации онакладных и товарах для сравнения приведено представление одних и тех же данныхс помощью реляционной (а) и постреляционной (б) моделей. Таблица INVOICES(накладные) содержит данные о номерах накладных (INVNO) и номерах покупателей(CUSTNO). В таблице INVOICE.ITEMS (накладные-товары) содержатся данные о каждойиз накладных: номер накладной (INVNO), название товара (GOODS) и количествотовара (QTY). Таблица INVOICES связана с таблицей INVOICE.ITEMS по полю INVNO.(см.Приложение рис.6.)
Как видно из рисунка, по сравнению среляционной моделью в постреляционной модели данные хранятся более эффективно,а при обработке не требуется выполнять операцию соединения данных из двухтаблиц. Для доказательства на рис.7 приводятся примеры операторов SELECT выбора данных из всех полей базы наязыке SQL для реляционной (а) ипостреляционной (б) моделей. (см. Приложение рис.7.)
Помимо обеспечения вложенности полейпостреляционная модель поддерживает ассоциированные многозначные поля(множественные группы). Совокупность ассоциированных полей называется ассоциацией.При этом в строке первое значение одного столбца ассоциации соответствует первымзначениям всех других столбцов ассоциации. Аналогичным образом связаны всевторые значения столбцов и т. д.
На длину полей и количество полей взаписях таблицы не накладывается требование постоянства. Это означает, чтоструктура данных и таблиц имеет большую гибкость.
Поскольку постреляционная модельдопускает хранение в таблицах ненормализованных данных, возникает проблемаобеспечения целостности и непротиворечивости данных. Эта проблема решаетсявключением в СУБД механизмов, подобных хранимым процедурам в клиент-серверныхсистемах.
Для описания функций контролязначений в полях имеется возможность создавать процедуры (коды конверсии и кодыкорреляции), автоматически вызываемые до или после обращения к данным. Кодыкорреляции выполняются сразу после чтения данных, перед их обработкой. Кодыконверсии, наоборот, выполняются после обработки данных. Достоинствомпостреляционной модели является возможность представления совокупностисвязанных реляционных таблиц одной постреляционной таблицей. Это обеспечиваетвысокую наглядность представления информации и повышение эффективности ееобработки. Недостатком постреляционной модели является сложность решенияпроблемы обеспечения целостности и непротиворечивости хранимых данных. Рассмотреннаянами постреляционная модель данных поддерживается СУБД uniVers. К числу других СУБД, основанных на постреляционноймодели данных, относятся также системы Bubba и Dasdb.
2.2 Многомерная модельданных
 
Многомерный подход кпредставлению данных в базе появился практически одновременно с реляционным, нореально работающих многомерных СУБД (МСУБД) до настоящего времени было оченьмало. C середины 90-х годов интерес к ним стал приобретать массовый характер.
Толчком послужила в 1993году программная статья одного из основоположников реляционного подхода Э.1Содда. B ней сформулированы 12 основных требований к системам класса OLAP (OnLine Analytical Processing — оперативная аналитическая обработка), важнейшие из которых связаны свозможностями концептуального представления и обработки многомерных данных.Многомерные системы позволяют оперативно обрабатывать информацию для проведенияанализа и принятия решения.
B развитии концепций ИСможно выделить следующие два направления:
·         системыоперативной (транзакционной) обработки;
·         системы аналитическойобработки (системы поддержки принятия решений).
Реляционные СУБДпредназначались для информационных систем оперативной обработки информации и вэтой области были весьма эффективны. B системах аналитической обработки онипоказали себя несколько неповоротливыми и недостаточно гибкими. Болееэффективными здесь оказываются многомерные СУБД (МСУБД).
Многомерные СУБД являются узкоспециализированнымиСУБД, предназначенными для интерактивной аналитической обработки информации.Раскроем основные понятия, используемые в этих СУБД: агрегируемость,историчность и прогнозируемость данных.
Агрегируемостъ данных означает рассмотрениеинформации на различных уровнях ее обобщения. B информационных системах степеньдетальности представления информации для пользователя зависит от его уровня:аналитик, пользователь-оператор, управляющий, руководитель.
Историчностъ данных предполагает обеспечениевысокого уровня статичности (неизменности) собственно данных и их взаимосвязей,а также обязательность привязки данных ко времени.
Статичность данныхпозволяет использовать при их обработке специализированные методы загрузки,хранения, индексации и выборки.
Временная привязка данныхнеобходима для частого выполнения запросов, имеющих значения времени и даты всоставе выборки. Необходимость упорядочения данных по времени в процессеобработки и представления данных пользователю накладывает требования намеханизмы хранения и доступа к информации. Так, для уменьшения времениобработки запросов желательно, чтобы данные всегда были отсортированы в томпорядке, в котором они наиболее часто запрашиваются.
Прогнозируемостъ данных подразумевает задание функцийпрогнозирования и применение их к различным временным интервалам.
Многомерность моделиданных означает не многомерность визуализации цифровых данных, а многомерноелогическое представление структуры информации при описании и в операцияхманипулирования дынными.
По сравнению среляционной моделью многомерная, организация данных обладает более высокий наглядностьюи информативностъю. Для иллюстрации на рис.8 приведены реляционное (а) имногомерное (б) представления одних и тех же данных об объемах продажавтомобилей.(см. Приложение рис.8.)
Если речь идет омногомерной модели с мерностью больше двух, то не обязательно визуальноинформация представляется в виде многомерных объектов (трех-, четырех- и болеемерных гиперкубов). Пользователю и в этих случаях более удобно иметь дело сдвухмерными таблицами или графиками. Данные при этом представляют собой«вырезки» (точнее, «срезы») из многомерного хранилища данных, выполненные сразной степенью детализации.
Рассмотрим основныепонятия многомерных моделей данных, к числу которых относятся измерение иячейка.
Измерение (Dimension) — это множествооднотипных данных, образующих одну из граней гиперкуба. Примерами наиболеечасто используемых временных измерений являются Дни, Месяцы, Кварталы и Годы. Вкачестве географических измерений широко употребляются Города, Районы, Регионыи Страны. B многомерной модели данных измерения играют роль индексов, служащихдля идентификации конкретных значений в ячейках гиперкуба.
Ячейка (Се11) илипоказатель — это поле, значение которого однозначно определяется фиксированнымнабором измерений. Тип поля чаще всего определен как цифровой. В зависимости оттого, как формируются значения некоторой ячейки, обычно она может бытьпеременной (значения изменяются и могут быть загружены из внешнего источникаданных или сформированы программно) либо формулой (значения, подобно формульнымячейкам электронных таблиц, вычисляются по заранее заданным формулам).
B примере на рис.8, бкаждое значение ячейки Объем продаж однозначно определяется комбинациейвременного измерения (Месяц продаж) и модели автомобиля. Еда практике зачастуютребуется большее количество измерений. Пример трехмерной модели данныхприведен на рис.9.(см. Приложение рис.9.)
B существующих МСУБДиспользуются два основных варианта (схемы) организации данных: гиперкубическаяи поликубическая.
B полукубической схемепредполагается, что в БД может быть определено несколько гиперкубов с различнойразмерностью и с различными измерениями в качестве граней. Примером системы,поддерживающей поликубический вариант БД, является сервер Оrас1е ExpressServer.
B случае гиперкубическойсхемы предполагается, что все показатели определяются одним и тем же наборомизмерений. Это означает, что при наличии нескольких гиперкубов БД все они имеютодинаковую размерность и совпадающие измерения. Очевидно, в некоторых случаяхинформация в БД может быть избыточной (если требовать обязательное заполнениеячеек).
B случае многомерноймодели данных применяется ряд специальных операций, к которым относятся:формирование «среза», «вращение», агрегация и детализация.
«Срез» (S1ice)представляет собой подмножество гиперкуба, полученное в результате фиксацииодного или нескольких измерений. Формирование «срезов» выполняется дляограничения используемых пользователем значений, так как все значения гиперкубапрактически никогда одновременно не используются. Например, если ограничитьзначения измерения Модель автомобиля в гиперкубе (рис.9) маркой «Жигули», тополучится двухмерная таблица продаж этой марки автомобиля различнымименеджерами по годам.
Операция «вращение»(Rotate) применяется при двухмерном представлении данных. Суть ее заключается визменении порядка измерений при визуальном представлении данных. Так,«вращение» двухмерной таблицы, показанной на рис.86, приведет к изменению еевида таким образом, что по оси X будет марка автомобиля, а по оси Y — время.
Операцию «вращение» можнообобщить и на многомерный случай, если под ней понимать процедуру измененияпорядка следования измерений. B простейшем случае, например, это может бытьвзаимная перестановка двух произвольных измерений.
Операции «агрегация»(Dri11 Up) и «детализация» (Dri11 Down)означают соответственно переход к более общему и к более детальномупредставлению информации пользователю из гиперкуба.
Для иллюстрации смыслаоперации «агрегация» предположим, что у нас имеется гиперкуб, в котором помимоизмерений гиперкуба, приведенного на рис.9, имеются еще измерения:Подразделение, Регион, Фирма, Страна. Заметим, что в этом случае в гиперкубесуществует иерархия (снизу вверх) отношений между измерениями: Менеджер,Подразделение, Регион, Фирма, Страна.
Пусть в описанномгиперкубе определено, насколько успешно в 1995 году менеджер Петров продавалавтомобили «Жигули» и «Волга». Тогда, поднимаясь на уровень выше по иерархии, спомощью операции «агрегация» можно выяснить, как выглядит соотношение продажэтих же моделей на уровне подразделения, где работает Петров.
Основным достоинствоммногомерной модели данных является удобство и эффективность аналитическойобработки больших объемов данных, связанных со временем. При организацииобработки аналогичных данных на основе реляционной модели происходит нелинейныйрост трудоемкости операций в зависимости от размерности БД и существенноеувеличение затрат оперативной памяти на индексацию.
Недостатком многомерной модели данных являетсяее громоздкость для простейших задач обычной оперативной обработки информации.
Примерами систем,поддерживающих многомерные модели данных, являются Essbase (Arbor Software),Media Mu1ti-matгix (Speedware), Oracle Express Server (Огас1е) и Cache(InterSystems). Некоторые программные продукты, например Media/M R (Speedware), позволяютодновременно работать с многомерными и с реляционными БД. B СУБД Cache, икоторой внутренней моделью данных является многомерная модель, реализованы триспособа доступа к данным: прямой (на уровне узлов многомерных массивов),объектный и реляционный.
2.3Объектно-ориентированная модель данных
Вобъектно-ориентированной модели при представлении данных имеется возможностьидентифицировать отдельные записи базы. Между записями базы данных и функциямиих обработки устанавливаются взаимосвязи с помощью механизмов, подобныхсоответствующим средствам в объектно-ориентированных языках программирования.
Стандартизованнаяобъектно-ориентированной модель описана в рекомендациях стандарта ODMG-93(Object Database Management Group — группа управления объектно-ориентированнымибазами данных). Реализовать в полном объеме рекомендации ODMG-93 пока не удается. Для иллюстрацииключевых идей рассмотрим несколько упрощенную модель объектно-ориентированнойБД.
Структураобъектно-ориентированной БД графически представима в виде дерева, узламикоторого являются объекты. Свойства объектов описываются некоторым стандартнымтипом (например, строковым — string) или типом, конструируемым пользователем(определяется как class).
Значением свойства типаstring является строка символов. Значение свойства типа class есть объект,являющийся экземпляром соответствующего класса. Каждый объект-экземпляр классасчитается потомком объекта, в котором он определен как свойство.Объект-экземпляр класса принадлежит своему классу и имеет одного родителя.Родовые отношения в БД образуют связную иерархию объектов.
Пример логическийструктуры объектно-ориентированной БД библиотечного цепа приведен на рис.10.(см.Приложение рис.10.)
Здесь объект типаБИБЛИОТЕКА является родительским для объектов-экземпляров классов АБОНЕНТ,КАТАЛОГ и ВЫДАЧА. Различные объекты типа КНИГА могут иметь одного или разныхродителей. Объекты типа КНИГА, имеющие одного и того же родителя, должныразличаться по крайней мере инвентарным номером (уникален для каждогоэкземпляра книги), но имеют одинаковые значения свойств isbn, удк, название иавтор.
Логическая структураобъектно-ориентированной БД внешне похожа на структуру иерархической БД.Основное отличие между ними состоит в методах манипулирования данными.
Для выполнения действийнад данными в рассматриваемой модели БД применяются логические операции,усиленные объектно-ориентированными механизмами инкапсуляции, наследования иполиморфизма Ограниченно могут применяться операции, подобные командам SQL(например, для создания БД).
Создание и модификация БДсопровождается автоматическим формированием и последующей корректировкойиндексов (индексных таблиц), содержащих информацию для быстрого поиска данных.
Рассмотрим кратко понятияинкапсуляции, наследования и полиморфизма применительно кобъектно-ориентированной модели БД.
Инкапсуляция ограничивает область видимости именисвойства пределами того объекта, в котором оно определено. 'Гак, если в объекттипа КАТАЛОГ добавить свойство, задающее телефон автора книги и имеющееназвание телефон, то мы получим одноименные свойства у объектов АБОНЕНТ иКАТАЛОГ Смысл такого свойства будет определяться тем объектом, в который оноинкапсулировано.
Наследование, наоборот, распространяет областьвидимости свойства на всех потомков объекта. Так, всем объектам типа КНИГА,являющимся потомками объекта типа КАТАЛОГ, можно приписать свойстваобъекта-родителя: isbn, удк, название и автор. Если необходимо расширитьдействие механизма наследования на объекты, не являющиеся непосредственнымиродственниками (например, между двумя потомками одного родителя), то в их общемпредке определяется абстрактное свойство типа abs. Так, определение абстрактныхсвойств 6wcem и номер в объекте БИБЛИОТЕКА приводит к наследованию этик свойстввсеми дочерними объектами АБОНЕНТ, КНИГА и ВЫДАЧА. Неслучайно поэтому значениясвойства билет классов АБОНЕНТ и ВЫДАЧА, показанных на рисунке, будутодинаковыми — 00015.
Полиморфизм в объектно-ориентированных языкахпрограммирования означает способность одного и того же программного кодаработать с разнотипными данными. Другими словами, он означает допустимость вобъектах разных типов иметь методы (процедуры или функции) с одинаковымиименами. Во время выполнения объектной программы одни и те же методы оперируютс разными объектами в зависимости от типа аргумента. Применительно к нашейобъектно-ориентированной БД полиморфизм означает, что объекты класса КНИГА,имеющие разных родителей из класса КАТАЛОГ, могут иметь разный набор свойств.Следовательно, программы работы с объектами класса КНИГА могут содержатьполиморфный код.
Поиск вобъектно-ориентированной БД состоит в выяснении сходства между объектом,задаваемым пользователем, и объектами, хранящимися в БД. Определяемыйпользователем объект, называемый объектом-цёлью (свойство объекта имеет тип goal), в общем случае может представлятьсобой подмножество всей хранимой в БД иерархии объектов. Объект-цель, а такжерезультат вьполнения запроса могут храниться в самой базе. Пример запроса ономерах читательских билетов и именах абонентов, получавших в библиотеке хотябы одну книгу, показан на рис.11. (см. Приложение рис.11.)
Основным достоинствомобъектно-ориентированной модели данных в сравнении с реляционной являетсявозможность отображения информации о сложных взаимосвязях объектов. Объектно-ориентированнаямодель данных позволяет идентифицировать отдельную запись базы данных иопределять функции их обработки.
Недостатками объектно-ориентированной моделиявляются высокая понятийная сложность, неудобство обработки данных и низкаяскорость выполнения запросов.
B 90-e годы существовалиэкспериментальные прототипы объектно-ориентированных систем управления базамиданных. B настоящее время такие системы получили широкое распространение, вчастности, К ним относятся следующие СУБД: POET (POET Software), Jasmine(Computer Associates), Versant (Versant Technologies), 02 (Ardent Software),ODB-Jupiter (научно-производственный центр «Интелтек Плюс»), а также Iris,Orion и Postgres.

Глава III. Сравнение классических моделейданных
При сравнении моделей данных оченьтрудно отделить факторы, характеризующие принципиальные особенности модели, отфакторов, связанных с реализацией этих моделей данных средствами конкретныхСУБД.
 
3.1 Достоинства и недостатки реляционноймодели
Рассматривая преимущества и недостаткиизвестных моделей данных, следует отметить ряд несомненных достоинствреляционного подхода:
·         Простота. Bреляционной модели всего одна информационная конструкция, которая формализуеттабличное представление данных, привычное для пользователей экономистов.
·         Теоретическоеобоснование. Наличие теоретически обоснованных методов нормализации отношений ипроверки ацикличности структуры позволяет получать базы данных с заданнымихарактеристиками.
·         Независимостьданных. Когда необходимо изменить структуру реляционной БД, это, как правило,приводит к минимальным изменениям в прикладных программах.
Среди недостатковреляционной модели данных необходимо назвать следующие.
·         Низкая скоростьпри выполнении операции соединения.
·         Большой расходпамяти для представления реляционной БД. Хотя проектирование в ЗНФ рассчитанона минимальную избыточность (каждый факт представляется в БД один раз), другиемодели данных обеспечивают меньший расход памяти для представления тех жефактов. Например, длина адреса связи обычно намного меньше, чем длина значенияатрибута.
 
3.2 Достоинства и недостаткииерархической модели
 
Достоинствамииерархической моделиданных являются следующие.
·         Простота. Хотямодель использует три информационные конструкции, иерархический принцип соподчиненностипонятий является естественным для многих экономических задач (например,организация статистической отчетности).
·         Минимальныйрасход памяти. Для задач, допускающих реализацию с помощью любой из трехмоделей данных, иерархическая модель позволяет получить представление сминимально требуемой памятью.
Недостаткииерархической модели.
·         Неуниверсальность.Многие важные варианты взаимосвязи данных невозможно реализовать средствамииерархической модели, или реализация связана с повышением избыточности в базеданных.
·         Допустимостьтолько навигационного принципа доступа к данным.
·         Доступ к даннымпроизводится только через корневое отношение.
 
3.3 Достоинства и недостатки сетевоймодели
Необходимо отметитьследующие преимущества сетевой модели данных.
·         Универсальность.Выразительные возможности сетевой модели данных являются наиболее обширными всравнении с остальными моделями.
·         Возможностьдоступа к данных через значения нескольких
 отношений (например,через любые основные отношения).
В качестве недостатковсетевой модели данных можно назвать.
·         Сложность, т.е.обилие понятий, вариантов их взаимосвязей и особенностей реализации.
·         Допустимостьтолько навигационного принципа доступа к данным.
Результаты, полученные дляациклических баз данных, позволяют говорить о равноценных возможностяхпредставления информации у ациклических реляционных БД, двухуровневых сетевыхБД и иерархической БД без логических связей.
При анализе моделей данных незатрагивалась проблема упорядоченности значений в отношениях баз данных. Дляреляционной модели данных эта упорядоченность с теоретической точки зрениянеобязательна, а в двух других моделях она широко используется для повышенияэффективности реализации запросов.
 

Заключение
 
Определение модели данныхпредусматривает указание множества допустимых информационных конструкций,множества допустимых операций над данными и множества ограничений для хранимыхзначений данных.
Модель данных, с однойстороны, представляет собой формальный аппарат для описания информационных потребностейпользователей, а с другой — большинство СУБД ориентируются на конкретную модельданных, и, таким образом, если информационные потребности удается точновыразить средствами одной из моделей данных, то соответствующая СУБД позволяетотносительно быстро создать работоспособный фрагмент ЭИС.
Информационныеконструкции, операции и ограничения моделей данных выбираются из достаточнонебольшого множества вариантов, характеризующего «крупные» информационныеобъекты и операции. B частности, не допускается рассмотрение отдельных символовданных, операций сложения атрибутов, ограничения на соответствие типов данных ит. п., что характерно для языков программирования.
Классификацияинформационных конструкций (информационных объектов) тесно связана с областью ихиспользования в ЭИС.
1. Объекты для технологиибаз данных — отношения и веерные отношения.
2. Объекты для технологииискусственного интеллекта — предикаты, фреймы и семантические сети.
3. Объекты для технологиимультимедиа — тексты, графические изображения, фонограммы и видеофрагменты.
Информационные объектыпослужили основой для объектно-ориентированного проектирования систем, когдафиксируется множество информационных объектов и действий над объектами.Типичный список действий включает в себя создание/уничтожение объекта,редактирование объекта, фиксацию одного объекта в качестве части другогообъекта, связывание объектов, синхронизацию действий над объектами.
Довольно-таки часто всеназванные объекты встраиваются в структуру отношений, которые можно считатьпростейшими универсальными объектами.
На окончательный выбор модели данныхвлияют многие дополнительные факторы, например, наличие хорошозарекомендовавших себя СУБД, квалификация прикладных программистов, размер базыданных и др.
B последнее время реляционные СУБДзаняли преимущественное положение как средство разработки ЭИС. Недостаткиреляционной модели компенсируются ростом быстродействия и ресурсов памятисовременных ЭВМ. Вследствие процессов децентрализации управления в экономикемногие базы данных ЭИС имеют простую структуру, которая легко трансформируетсяв понятные системы таблиц (отношений).

Список использованной литературы
 
1.        Мишенин А.И.Теория экономических информационных систем.-М.: «Финансы и статистика», 2007
2.        Семакин И.Г.Хеннер Е.К. Информационные системы и модели. Учебное пособие.-М.: «БИНОМ.Лаборатория знаний», 2005
3.        Смирнова Г.Н.Сорокин А.А. Тельнов Ю.Ф. Проектирование экономических информационныхсистем.-М.: «Финансы и статистика», 2003
4.        Хомоненко А.Д.Цыганков В.М. Мальцев М.Г. Базы данных. Учебник для высших учебныхзаведений.-Санкт-Петербург: «КОРОНА принт», 2004
5.        http://www.finstat.ru
6.        http://www.refer.ru

Приложение
/>
Рис.1. Представлениесвязей в иерархической модели
 
(Хомоненко А.Д. ЦыганковВ.М. Мальцев М.Г. Базы данных. Учебник для высших учебныхзаведений.-Санкт-Петербург: «КОРОНА принт», 2004)
/>
Рис.2. Пример типа«дерево»
 
(Хомоненко А.Д. ЦыганковВ.М. Мальцев М.Г. Базы данных. Учебник для высших учебныхзаведений.-Санкт-Петербург: «КОРОНА принт», 2004)
/>
Рис.3. данные виерархической базе
 
(Хомоненко А.Д. ЦыганковВ.М. Мальцев М.Г. Базы данных. Учебник для высших учебныхзаведений.-Санкт-Петербург: «КОРОНА принт», 2004)
/>
Рис.4. Представлениесвязей в сетевой модели
 
(Хомоненко А.Д. ЦыганковВ.М. Мальцев М.Г. Базы данных. Учебник для высших учебныхзаведений.-Санкт-Петербург: «КОРОНА принт», 2004)
/>
Рис.5. Пример схемысетевой БД
 
(Хомоненко А.Д. ЦыганковВ.М. Мальцев М.Г. Базы данных. Учебник для высших учебныхзаведений.-Санкт-Петербург: «КОРОНА принт», 2004
А)
 
INVOICES
/>
INVOICE.ITEMS
/>
Б)
 
INVOICES
/>
Рис.6. Структурыданных реляционной и постреляционной моделей
 
(Хомоненко А.Д. ЦыганковВ.М. Мальцев М.Г. Базы данных. Учебник для высших учебныхзаведений.-Санкт-Петербург: «КОРОНА принт», 2004)
А)
SELECT
 INVOICES.INVNO,CUSTNO, GOODS, QTY
FROM
 INVOICES,INVOICE.ITEMS
WHERE
 INVOICES.INVNO=INVOICE.ITEMS.INVNO$
Б)
SELECT
 INVNO,CUSTNO, GOODS, QTY
FROM
 INVOICES;
Рис.7. Операторы SQLдля реляционной и постреляционной моделей
(Хомоненко А.Д. ЦыганковВ.М. Мальцев М.Г. Базы данных. Учебник для высших учебныхзаведений.-Санкт-Петербург: «КОРОНА принт», 2004)
А)
/>
Б)
/>
Рис.8. Реляционные и многомерноепредставление данных
(Хомоненко А.Д. ЦыганковВ.М. Мальцев М.Г. Базы данных. Учебник для высших учебныхзаведений.-Санкт-Петербург: «КОРОНА принт», 2004)
/>
Рис.9. Пример трехмерноймодели
(Хомоненко А.Д. ЦыганковВ.М. Мальцев М.Г. Базы данных. Учебник для высших учебныхзаведений.-Санкт-Петербург: «КОРОНА принт», 2004)
/>
Рис.10. Логическаяструктура БД библиотечного дела
(Хомоненко А.Д. ЦыганковВ.М. Мальцев М.Г. Базы данных. Учебник для высших учебныхзаведений.-Санкт-Петербург: «КОРОНА принт», 2004)
/>
Рис.11. Фрагмент БД собъектом-целью
(Хомоненко А.Д. ЦыганковВ.М. Мальцев М.Г. Базы данных. Учебник для высших учебныхзаведений.-Санкт-Петербург: «КОРОНА принт», 2004)