Реляционная (или основанная на таблицах) модель базы данных безусловно наиболее часто используется сегодня и представлена как большими коммерческими пакетами, как Oracle, Sybase, Informix, Ingres и Gupta, так и маленькими как DBaseIV, Access, FoxPro, Alpha4 и Paradox. Все они основаны на первой теоретической работе Кодда и др. 1970 года. Из трех моделей, реляционная модель имеет наиболее хорошую математическую базу, включающую реляционную алгебру и реляционное исчисление. Последнее является основой языка запросов SQL и расширения ODBC, которые широко применяются для подключения пользовательского интерфейса в 2-х и 3-х слойных приложениях клиент/сервер. 

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

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

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

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

Объектно-ориентированные БД - относительно новая концепция и, как таковая, не имеет четкого определения. Требования, которым должна отвечать " объектно-ориентированная " БД, целиком и полностью лежат на совести их авторов. Свойства, представляющиеся общими для большинства реализаций, таковы: 1. Абстракция: Каждая реальная "вещь", которая хранится в БД, является членом какого-либо класса. Класс определяется как совокупность свойств (properties), методов (methods), общедоступных (public) и частных (private) структур данных, а также программы, применимых к объектам (экземплярам) данного класса. Классы представляют собой ни что иное, как абстрактные типы данных. Методы - это процедуры, которые вызывается для того, чтобы произвести какие-либо действия с объектом (например, напечатать себя или скопировать себя). Свойства - это значения данных, связанные с каждым объектом класса, характеризующие его тем или иным образом (например, цвет, возраст). Свойства присутствуют не во всех реализациях, по сути дела, они являются краткой записью методов без аргументов (таких как "сообщите свой цвет", "сообщите свой возраст"). 2. Инкапсуляция: Внутреннее представление данных и деталей реализации общедоступных и частных методов (программ) является частью определения класса и известно только внутри этого класса. Доступ к объектам класса разрешен только через свойства и методы этого класса или его родителей (см. ниже "наследование"), а не путем использования знания подробностей внутренней реализации. 3. Наследование (одиночное или множественное): Классы определены как часть иерархии классов. Определение каждого класса более низкого уровня наследует свойства и методы его родителя, если они только они явно не объявлены ненаследуемыми или изменены новым определением. При одиночном наследовании класс может иметь только один родительский класс (т.е. классовая иерархия имеет древовидную структуру). При множественном наследовании класс может происходить от многочисленных родителей (т.е. иерархия классов имеет структуру ориентированного нециклического графа, не обязательно древовидную). Не все объектно-ориентированные СУБД поддерживают множественное наследование. 4. Полиморфизм: Несколько классов могут иметь совпадающие имена методов и свойств, даже если они считаются различными. Это позволяет писать методы доступа, которые будут правильно работать с объектами совершенно различных классов, лишь бы соответствующие методы и свойства были в этих классах определены. 5. Сообщения: Взаимодействие c объектами осуществляется путем посылки сообщений с возможностью получения ответов. Это отличается от традиционного для других моделей вызова процедур. Для того, чтобы применить метод к объекту, надо послать ему сообщение типа "примени к себе данный метод" (например, "напечатай себя"). Парадигма пересылки сообщений не всегда используется в объектно-ориентированных базах данных, однако типична для "истинно" ОО-реализаций.

 

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

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

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

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

К сожалению, объектно-ориентированный подход пока не столь широко испытан и не настолько "зрел", как остальные два подхода. Наиболее доступный подход к объектно-ориентированной БД - это наложить ее на реляционную или древовидную модель. Так как ООП в большей степени связан с процессом, чем со структурой, представляется, что древовидная модель подходит лучше. Создавая ООБД на основе реляционной структуры, приходится жертвовать свободой, радовавшей на стадии разработки, когда дело доходит до внедрения и сопровождения.2)Преожение SELECT языка SQL. Выборка с использованием IN, вложенный SELECT. Подзапрос с несколькими уровнями вложенности. Коррелированный подзапрос.

SELECT column_name FROM table_name; - простейший вариант селекта

Например: - исходная таблица SELECT LastName, FirstName FROM Persons;

- выводится на экран

SELECT * FROM Persons; - выводит всю таблицу

SELECT IN: SELECT column_name FROM table_name WHERE column_name IN (value1,value2,..); SELECT SUM(Sales) FROM Store_Information          WHERE Store_name IN (SELECT store_name FROM Geography WHERE region_name = 'West');

3)Использование средств IBM System i для организации защиты систем на основе MS Windows от вирусов.

ЭТО БРЕД КАКОЙ-ТО((

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

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

Что же делает System i? Он играет роль жёсткого диска. Или как файл-сервера. Все ПК под управлением Windows при включении цепляются к нему. И ПК думая что работает с обычным жёстким диском, на самом деле работает с выделенным местом на system i. Т.е. все файлы, все копирования/перемещения, всё проходит на сервере system i. Пользователь, работая в обычном виндосе, разницы не ощущает.

Так какова же защита? System i наставляет каждому исполняемому файлу свой уровень доступа. Пользователь Windows сознательно сможет изменить файл. Но вирус скрытно этого сделать не сможет, ибо, грубо говоря, не знает пароля J А тем более вирус не может скрытно вписаться и функционировать на system I, т.к. исполняемые файлы виндоса функционируют только из под виндоса но никак не самстоятельными действиями system i.

 

 

Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 42 - Предложение SELECT FOR XML. Параметры RAW, AUTO, EXPLICIT. Параметр XMLDATA и его назначение.
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и