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

24.03.2019

Введение

1.6.1 Последствия

Примечания

Введение

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

1. История Informix

1год: начало

Роджер Сипл и Лора Кинг работали в Cromemco, где они разработали небольшую реляционную СУБД базирующуюся на ISAM, которая была частью программного комплекса для формирования отчетов.

Впоследствии Сипл и Кинг покинули Cromemco и основали свою собственную компанию Relational Database Systems (RDS) в 1980 году. Их первым продуктом стал Marathon - 16-битная версия их ранней реализации ISAM. Marathon предназначался для операционной системы Onyx - версии Unix для ранних микропроцессоров ZiLOG.

В RDS они сконцентрировались на раширяющемся рынке реляционных СУБД и выпустили собственный продукт под маркой Informix (INFORMation on unIX) в 1981 году. В составе Informix поставлялся их собственный язык Informer. Также в состав пакета входил формировщик отчетов ACE, который позволял извлекать данные из базы данных и представлять их в удобной для чтения форме. Инструмент PERFORM, позволял пользователям интерактивно обращаться к данным в базах данных и редактировать их. Финальным релизом стала версия 3.30, выпущенная в начале 1986 года.

В 1985 году RDS представила новый, основанный на SQL, движок запросов в составе INFORMIX-SQL (ISQL) версии 1.10 (версия 1.00 никогда не выпускалась). Продукт включал новые версии ACE и PERFORM, которые теперь поддерживали SQL. Самым значительным отличием ISQL от предыдущей версии Informix стало выделение кода доступа к базе данных в процесс движка (sqlexec) - ранее он являлся частью клиента. Это стало этапом перехода к клиент-серверной модели вычислений. Эволюционировавший ISAM, который был по сути ядром Informix, в новой инкарнации получил название C-ISAM.

В начале 1980-х Informix оставался мелким игроком на рынке СУБД, но с ростом популяроности UNIX и SQL в середине 1980-х, доля Informix заметно выросла. К 1986 году они стали достаточно большими для IPO. Название компании меняется на Informix Software. Продукты включали в себя INFORMIX-SQL версии 2.00 и INFORMIX-4GL 1.00. Они поставлялись как в составе движка СУБД, так и как самостоятельные инструменты (ISQL и I4GL соответственно).

Серия последующих релизов, предствившая новый движок запросов, получила известность как INFORMIX-Turbo. Turbo использовал новый RSAM, который был более производительным в многопользовательской среде по сравнению с C-ISAM. С релизом версии 4.00 в 1989 году, Turbo был переименован в INFORMIX-OnLine (название отражало возможность создания резервных копий баз данных при работающем сервере и пользователях, изменяющих данные в момент создания бэкапа). Также оригинальный продукт, основанный на C-ISAM был отделен от инструментов (ISQL и I4GL) и назван INFORMIX-SE (Standart Engine). Выпущенная под конец 1990 года версия 5.00 обладала полноценной поддержкой распределенных транзакций с двухфазным подтверждением и хранимых процедур. В версии 5.01 также появилась возможность использовать триггеры.

1год: приобретение Innovative Software

В 1988 году Informix приобретает Innovative Software, производители офисных систем для Unix и DOS под маркой SmartWare и WingZ, инновационная программа по работе с электронными таблицами для Apple Macintosh.

WingZ предоставлял продвинутый графический интерфейс, поддерживал объемные электронные таблицы, а также предоставлял возможность программирования на языке HyperScript, который имел некоторое сходство с языком HyperCard. Оригинальный релиз был весьма успешным в свое время: WingZ был на втором месте по популярности после Microsoft Excel. В 1990 году WingZ был портирован на большое число других платформ (в большинстве своем это были Unix-системы). В этот период начались повальные инвестирования в рабочие станции на базе Unix, что позволило бы использовать их для обработки больших финансовых моделей. Некоторое (не очень продолжительное) время WingZ был достаточно успешным в своей нише. Несмотря на это, он страдал от недостатка девелоперских и маркетинговых ресурсов, возможно из-за общего недопонимания рынка не-серверных приложений. В начале 1990-х WingZ стал неконкурентоспособным и был продан в 1995 году. Также Informix продал лицензию Clarise, которая скомбинировала WingZ с обновленным графическим интерфейсом. Результатом стал продукт Claris Resolve.

1год: динамически масштабируемая архитектура

После неудачи на рынке офисного ПО, Informix перефокусировался на растущий рынок серверов баз данных. В 1994 году, в результате сотрудничества с Sequent Computer Systems, Informix выпускает версию 6.00 своей СУБД. Главным нововведением стала Динамически Масштабируемая Архитектура (Dynamic Scalable Architecture, DSA).

В мае 2004 года Министерство юстиции заявило, что Уайт приговорен к двум годам в федеральной тюрьме, штрафу в 10 тыс. долл, двум годам условно и 300 часам общественных работ . Заявление также гласило, что объём ущерба, нанесенный акционерам действиями Уайта не может быть адекватно оценен из материалов дела.

Гражданин Германии и резидент Уолтер Кёнигседер, заместитель вице-президента компании по европейскому направлению, также был обвинен. Но Верховному Суду так и не удалось добиться его экстрадиции.

В ноябре 2005 года вышла книга, рассказывающая о взлете и падении Informix. Она написана одним из старейших сотрудников Informix. «Реальная история Informix Software и Фила Уайта: Уроки бизнеса и лидерства для руководства» позволяла взглянуть на историю компании изнутри глазами одного из сотрудников. В книге содержится детальное описание успехов компании на начальном этапе, ужасного падения и того, каким образом генеральный директор Фил Уайт оказался в тюрьме.

1год: другие приобретения

Начиная с 2001 года, главные события в жизни Informix перестают касаться технических инноваций. В марте компания приобретает Ardent Software, компанию история которой состоит из слияний и поглощений. Это приобретение добавило мультипространственные движки UniVerse и UniData (вместе известные как U2) к уже достаточно большому к тому времени списку СУБД-движков в портфолио компании, которое включало в себя не только семейство Informix, но и ориентированный на хранилища данных SQL-движок Red Brick и 100 % Java-версию SQL, Cloudscape (которая впоследствии была включена в соответствующую имплементацию J2EE).

Таким образом на момент приобретения Informix IBM линейка продуктов состояла из:

1.8. IBM приобретает Informix

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

В апреле 2001 года IBM, ведомая предложением Wal-Mart (крупнейший клиент Informix), приобретает у Informix технологию СУБД, бренд, планы для будущих разработок (внутренний проект под кодовым именем «Arrowhead»), а также базу в 100 000 клиентов. Оставшиеся ресурсы по разработке приложений и инструментариев образуют новую компанию Ascential Software . В мае 2005 года IBM приобретает Ascential, воссоединяя там самым ресурсы Informix под собственным лейблом Information Management Software.

2. Текущие планы

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

IBM Informix

кодовым названием

12 июня 2007 года СУБД IBM Informix 11.1 Cheetah был официально представлен общественности.

Одновременно с объявлением о выходе новой версии Informix 11.1 IBM объявила о том, что DB2 и IBM Informix Dynamic Server будут развиваться параллельно и независимо друг от друга. Запланированное ранее объединение двух продуктов отменено. IBM Informix будет развиваться и позиционироваться на рынке в качестве СУБД для высокопроизводительных OLTP систем, в то время как DB2 будет идеальной СУБД для Data Warehouse. Новая версия сервера будет поддерживать сервис-ориентированную архитектуру (Service-Oriented Architecture, SOA), что поможет в интеграции приложений.

Основными нововведениями данной версии являются: новый алгоритм обработки контрольной точки (теперь работа приложений не блокируется в момент выполнения контрольной точки), возможность создания нескольких вторичных серверов в репликации. Появился абсолютно новый уровень изоляции - LAST COMMITTED READ, позволяющий получать самую последнюю принятую версию строк, даже если другой параллельный сеанс удерживает исключительную блокировку на уровне строк.

С версии Informix 11.1 появилась 64-битная версия для платформы Windows.

новый менеджер

подходящий сервер

статистическую информацию

С версии Informix 11.5 появилась поддержка платформы Mac OS.

Informix Developer Edition

различных платформ

Informix Developer Edition

коммерческих целях

техническая поддержка

Следующим этапом развития должна стать СУБД IDS v12.00, известная под рабочим названием Panther.

Informix Innovator-C

Informix Ultimate-C

Ultimate Edition

Informix Ultimate-C

3. Описание продуктов

Informix - СУБД класса Enterprise (корпоративная), подходящая для управления данными в малом, среднем и крупном бизнесе.

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

Поддерживаются почти все известные серверные платформы: IBM AIX, Linux (RISC and i86), HP UX, SGI Irix, Solaris, Windows, Mac OS.

В линейку программных продуктов под общим названием «Informix» входят следующие СУБД:

IBM Informix Dynamic Server Enterprise Edition (IDS)

высокой производительности

разные виды

определённые пользователем

IBM Informix Dynamic Server Enterprise Edition with J/Foundation

IBM Informix Extended Parallel Server (XPS)

больших баз

быстрой загрузки

Идеальное решение

IBM Informix Dynamic Server (IDS) Express

данного сервера

минимальный уровень

повышенной производительности

IBM Rational

Visual Studio

IBM Informix OnLine Extended Edition

IBM Informix Standard Engine (SE)

IBM Informix Red Brick Warehouse

Примечания

Новые возможности Informix 11.1 - publib. boulder. /infocenter/idshelp/v111/topic/com. ibm. po. doc/new_features. htm Новые возможности Informix 11.5 - publib. boulder. /infocenter/idshelp/v115/topic/com. ibm. po. doc/new_features. htm

ЛЕКЦИЯ

Логические модели данных.

Иерархические, сетевые, реляционные модели данных.

Принципы построения.

Преимущества и недостатки

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

11.1. О понятии «модель данных»

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

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

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

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

Итак, модель данных – модель логического уровня проектирования БД. Ее можно рассматривать как сочетание трех компонентов (слайд 2 ):

1. Структурный компонент, т.е. набор правил, по которым может быть построена БД.

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

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

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

Существуют три основных типа логических моделей данных на основе записей ( слайд 3 ):

- реляционная модель данных (relational data model );

- сетевая мо дель данных (network data model );

- иерархическая модель данных (hierarchical data model ).

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

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

Реляционная модель данных основана на понятии математических отношений. В реляционной модели данные и связи представлены в виде таблиц, каждая из которых имеет несколько столбцов с уникальными именами. На слайде (слайд 4 ) показан пример реляционной схемы, содержащей сведения о кафедрах ВУЗа и кадровом составе. Например, из таблицы «Кадровый состав» видно, что сотрудник Иванов И.И. работает в должности заведующего кафедрой 22, которая, согласно данным из таблицы «Структура», расположена в корпусе А, в комнате 322. Здесь важно отметить, что между отношениями «Кадровый состав» и «Структура» существует следующая связь: сотрудник работает на кафедре. Однако между этими двумя отношениями нет явно заданной связи: ее существование можно заметить, только зная, что атрибут Каф в отношении «Кадровый состав» эквивалентен атрибуту Каф в отношении «Структура».

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

На слайдах (слайды 5, 6 ) представлена реляционная модель данных для ПрО «сотрудники-проекты-детали-поставщики».

11.3. Сетевая модель данных

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

Самой популярной сетевой СУБД является система IDMS / R фирмы Computer Associates .

На слайдах (слайды 8, 9 ) представлены варианты сетевой модели данных для ПрО «сотрудники-проекты-детали-поставщики».

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

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

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

На слайдах (слайды 11, 12 ) представлена варианты иерархической модели данных для ПрО «сотрудники-проекты-детали-поставщики».

11.5. Преимущества и недостатки моделей

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

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

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

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

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

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

11.6. Документальные системы и интеграция моделей

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

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

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

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

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

Рисунок 1 Схема иерархической модели данных

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

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

Указанный недостаток снят всетевой модели, где, теоретически возможны связи «всех информационных объектов со всеми» (рис. 2). Пример – учебное заведение, где каждый преподаватель может обучать много (теоретически всех) студентов, и каждый студент может обучаться у многих (теоретически всех) преподавателей.

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

Рисунок 2 Сетевая структура модели данных

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

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

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

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

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

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

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