Объектные модели данных. Объектная модель

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

• - абстрагирование;
• - инкапсуляция;
• - модульность;
• - иерархичность.

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

• - типизация;
• - параллелизм;
• - сохраняемость.

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

Абстрагирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим элементы реализации нашей абстракции на языке С++.

typedef float Temperature; // Температура по Цельсию

typedef unsigned int Location; // Число, однозначно определяющее

// положение датчика

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

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

struct TemperatureSensor {

Temperature curTemperature; // текущая температура в

// местонахождении датчика

Location loc; // местонахождение датчика

void calibrate (Temperature actualTemperature); // калибровать

Temperature currentTemperature (); // текущая температура

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

Объекты данного типа вводятся так же, как и переменные стандартных типов:

TemperatureSensor TSensors; // массив из ста объектов типа

// TemperatureSensor

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

TSensors . calibrate (0.); // калибруется датчик номер 3

Поскольку имя объекта, для которого вызывается функция-член, неявно ей передается, в списках аргументов функций отсутствует аргумент типа TemperatureSensor, задающий конкретный датчик, над которым производятся действия. К этому объекту внутри функции можно явно обратиться по указателю this. Например, в теле функции calibrate можно написать один из двух эквивалентных операторов

this -> curTemperature = actualTemperature;

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

Рассмотрим инварианты, связанные с операцией currentTemperature. Предусловие включает предположение, что датчик установлен в правильном месте в теплице, а постусловие - что датчик возвращает значение температуры в градусах Цельсия.

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

Для проверки условий язык С++ предоставляет специальные средства в библиотеке assert.h.

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

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

Исключение возбуждается посредством указания ключевого слова throw с необязательным аргументом-выражением. Исключение будет обработано посредством вызова того обработчика catch, тип параметра которого будет соответствовать типу аргумента throw. При наличии вложенных блоков try (например, из-за вложенности вызовов функций) будет использован обработчик самого глубокого блока. Если обработчика, соответствующего типу аргумента throw, на данном уровне не будет найдено, будет осуществлен выход из текущей функции и поиск в блоке try с меньшей глубиной вложенности и т.д. После обработки исключения управление передается на оператор, следующий за описаниями обработчиков catch.

Пример. Рассмотрим стек, реализованный с использованием массива фиксированной длины.

int stack; // не более ста элементов в стеке

int top=-1; // номер доступного элемента

void push (int el) {

if(top == 99) throw (1); // проверить на переполнение

else stack[++top] = el; // поместить элемент в стек

if(top == -1) throw (0); // проверить на пустоту

else return stack; // извлечь элемент из стека

try{ // пробный блок

catch(int error){. . .} // если error = 0, то стек пуст;

// если error = 1, то стек полон

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

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

Каждому объекту в момент создания присваивается идентификатор объекта OID. Он обладает следующими свойствами:

1. Генерируется системой

2. Уникально обозначает этот объект

3. Его нельзя изменить пока объект продолжает существовать

4. После создания объекта его идентификатор нельзя использовать повторно в дальнейшем при любых условиях.

5. Не зависит от значений атрибутов объекта, т.е. 2 объекта могут и иметь одинаковое состояние, но они всегда обладают разными OID.

6. В идеале – OID скрыто от пользователей.

За счет OID целостность сущностей гарантируется автоматически.

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

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

Классы – группировка одинаковых объектов.

Наследование – один класс определяется как частный случай (подкласс) более общего класса (суперкласс). Подкласс наследует все свойства суперкласса + доп. определяет свои собственные атрибуты и методы. Все экземпляры под класса являются экземплярами суперкласса. Принцип подстановки: экземпляр под класса всегда может пользоваться любым методом/атрибутом суперкласса или в любой конструкции, где используется суперкласс. Понятие под-, суперкласса и наследования существует также в расширенной РБД модели. Однако в чисто объектной модели наследование относится и к состоянию и к поведению.

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

Динамическое связывание позволяет отложить линковку до выполнения.

Объектные модели

Объектная модель поволяет решить некоторые проблемы связанные с некоторыми реляционными базами.

Проблемы:

1. Поддержка нескольких версий

Управление версиями- это процесс сопровождения эволюциями объекта.

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

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

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

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

2. Поддержка продолжительных транзакций

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

Вырианты решения проблем: 1) вводится протокол управления параллельным выполнением с временными метками.

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

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

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

1) Определяется временная отметка самой старой транзакции в системе, все то ниже этой транзакции удалятется.

2) Вводятся усовершенствованные модели транзакциий. (полная транзакция раскладывается в древовидную структуру сумм транзакций которые выполняются в параллельном режиме.

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

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

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

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

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

Недостаток: практически объектная база пишется в ручную.

В объектной базе имеются аналогии с основными приемами работы в реляционной базе.

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

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

Ссылочная целостность.

Варианты управления: 1) пользователю запрещается явно удалять объекты, система сама удаляет объекты которые становятся недоступными.

2) пользователю разрешается удалять объекты когда они становятся ненужными, тогда система автоматически обнаруживает недействительные ссылки и присваивает недействительную ссылку NULL.

3) пользователю разрешается изменять и удалять объекты, а система использует обратные атребуты.

ОБЩАЯ ХАРАКТЕРИСТИКА ОБЪЕКТНО РЕЛЯЦИОННОЙ МОДЕЛИ ДАННЫХ

Общая идея ОР модели состоит в дополнении Р модели объектно ориентированными возможностями, а именно добавляется расширяемая пользователем система типов данных, добавляется инкапсуляция, наследование и полиморфизм, добавляется использование сложных объектов, и добавляется идентификация объектов.

Приемущества: повторное и совместное использование стандартных компонентов.

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

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

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

Недостатки: Искажение объектной идеологии.

РАСШИРЕННЫЙ СТАНДАРТ SQL 3. ОСНОВА ДЛЯ ПОСТРОЕНИЯ ОБЪЕКТНО РЕЛЯЦИОННЫХ БД

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

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

Как правило процедуры или функции пишутся вне СУБД, и вызываются в SQL с помощью оперотора CALL.

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

Поддержка больших объектов. Большой объект - поле таблицы которое содержитпрои значительное количество данных.

В стандарте SQL содержится три топа больших объектов:

1) большой двоичный объект

2) большой символьный объект

В стандарте SQL 3 допускается выполнение некоторых операций с объектами: например оператор конкатенации - возвращает символьную строку образованную соединением символьных строк в указанном порядке.

Есть функции извлечения символьной подстроки:

Функция перекрытия строк.

Функция свертки преобразования регистра.

Функция вычисления длины строки.

МОДЕЛЬ ХРАНИЛИЩА ДАННЫХ

Хранилище данных- это предметно ориентированный, интегрированный, привязанный ко времени и не изменяемый набор данных, предназначенный для поддержки принятия решений.

Хранилище данных имеет много общего с реляционной моделью.

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

2) Данные не обновляются, а только пополняются.

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

4) Базовым объектом модели хранилища является привязанный ко времени факт.

5) Основная операция это агрегирование и основная проблема максимальная скорость доступа к факту.

Хранилище данных.

Базы данных в концепции хранилища описываются с использованием метода «моделирование размерностей».

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

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

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

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

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

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

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

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

Схема снежинка - вариант схемы звезда, в которой каждая размерность может иметь своих собственные размерности.

Приимущество хранилищ данных:

1. Эффективность - единообразие структуры обеспечивает более эффективный доступ к данным, независимо от средств доступа.

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

3. Расширяемость - типичные изменения:

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

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

3. Добавление новых атрибутов.

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

Модель данных OLAP

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

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

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

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

3. Существует мощнейший мат аппарат для работы с многомерными кубами, это матрицы.

1. С ростом числа размерностей кол-во ячеек в кубе возрастает экспоненциально, время обработки многомерного запроса увеличивается.

2. Как правило такие структуры представляют собой сильно разреженные матрицы. Много NULL.

Для создания эффективной многомерной базы возможно несклолько путей:

1. Выявить иерархическую структуру в данных.

2. Выявить другие порядки типа решетка типичных размерностей.

3. Разбиение гиперкуба на много маленьких кубов с заполненными ячейками.

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

Модель слабоструктурированных данных

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

Если в СУБД должны храниться слабоструктурированные данные, то субд должна формировать схему на основе этих данных.

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

Варианты записи слабоструктурированных данных:

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

2. Язык XML - мета язык, язык для описания других языков. Система определения структурированных типов документов и языков разметки, представляющих экземпляры документов данного типа. Достоинтсва:

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

2. Позволяется наглядно описать структуру данных. Можно использовать для описания гетерогенных (разнородны) БД.

3. Позволяет хранить содержимое документа и отдельно (независимо) способ его представления.

Реляционная алгебра и реляционное исчисление

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

Существует альтернативный вариант для описания запроса который называется логические исчисления.

Существует два варианта реляционной логики - это исчисление кортежей, и исчисление доменов.

Исчисление кортежей - переменной является кортеж(строчка) тела отношения.

Для формирования условий выборки из набора отношений используются так называемые правильно построенные формулы (well formed formula) - это условия накладываемые на кортежные переменные.

Пример: СЛУЖАЩИЙ СЛ_НОМ= НАЧАЛЬНИК НАЧ_НОМ

Для построения WFF используются логические связки и правила мат логики.

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

Таким образом это эквивалентно тому, что система по умолчанию выполняет операцию join.

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

Сопостовление Реляционной алгебры и Реляционного исчисления.

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

Примеры: Субд которые работают на линукс это INGRES (Integratie graphics retrielale System)(хз че написано у нее подчерк кривой).

И язык табличная форма Query by Example

Резюме

Недостатки модели TCP/IP

Несмотря на огромную популярность, у модели TCP/IP и ее протоколов имеется ряд недостатков:

· отсутствие разграничений концептуальных понятий интерфейса, протокола и уровневого сервиса, что достаточно четко сделано в модели ISO/OSI. Вследствие этого модель TCP/IP не может применяться при разработке новых сетей;

· с помощью модели TCP/IP нельзя описать никакой другой стек протоколов, кроме TCP/IP;

· в модели не различаются физический и канальный уровни, в то время как они абсолютно разные и в корректной модели это должно учитываться;

· наиболее тщательно продуманы и проработаны протоколы IP и TCP. Многие из других протоколов стека разрабатывались студентами (студентам к размышлению!) и свободно распространялись, вследствие чего широко укоренились в практике и теперь их трудно заменить на что-либо новое, предлагаемое по коммерческой схеме.

В качестве резюме отметим, что модель ISO/OSI является полезной для теоретических исследований и разработок новых сетей, хотя протоколы OSI не получили широкого распространения. Для TCP/IP можно сделать обратное утверждение: стек не может рассматриваться в качестве полноценной модели, тогда как сами протоколы хорошо апробированы и чрезвычайно популярны.

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

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

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

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

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

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

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

Иерархия программного обеспечения (ПО) может быть представлена в следующем виде:

· прикладное ПО;

· промежуточное ПО;

· базовое ПО.

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

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

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

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

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

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

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

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

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

· прикладной протокол (Application Protocol, АР) – логический интерфейс между прикладными объектами;

· интерфейс прикладных программ (Application Program Interface, API) – логический интерфейс между прикладными объектами и объектами промежуточного ПО, которые поддерживают прикладные объекты;

· протокол промежуточного ПО (Managing Protocol, МР) – логический интерфейс между объектами промежуточного ПО;

· интерфейс базовых программ (Base Program Interface, ВРІ) – логический интерфейс между объектами промежуточного и базового ПО, которые поддерживают объекты промежуточного ПО;

· интерфейс человек-компьютер (User-Computer Interface, UCI) – логический интерфейс между пользователем и, главным образом, объектами базового ПО, однако он может включать в себя также логический интерфейс с объектами промежуточного ПО и даже объектами приложений.

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

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

Рис. 1. Верхняя панель инструментов

Рис. 2. Боковая панель инструментов. Блок "Перечисления"

В системе ELMA выделяют системные и пользовательские объекты и перечисления. Пользовательские объекты и перечисления создаются администратором системы в Дизайнере ELMA.

Системные объекты или перечисления – это объекты или перечисления, спроектированные и настроенные разработчиками системы ELMA. Данные объекты и перечисления не могут быть удалены, но подлежат расширению . В списке системные объекты и перечисления отображены синим цветом.

Пользовательские объекты или перечисления – это объекты или перечисления, спроектированные и настроенные в Дизайнере ELMA с учетом требований каждой конкретной компании. Данные объекты и перечисления могут быть созданы пользователями системы, изменены и/или удалены . В списке пользовательские объекты и перечисления отображены черным цветом.

Режимы отображения объектов и перечислений в списке

Списки объектов и перечислений могут быть отображены в нескольких режимах: "Отображаемое имя" и "Имя класса". Выбор режима отображения объектов и перечислений осуществляется из выпадающего списка (рис. 3), расположенного в поле Показывать в боковом меню вкладки Объекты в Дизайнере ELMA.

Рис. 3. Дизайнер ELMA. Вкладка "Объекты". Поле "Показывать"

Каждый объект и перечисление имеют несколько имен:

Отображаемое имя – имя объекта и/или перечисления, отображаемое списке объектов в Дизайнере ELMA, в карточке объекта и/или перечисления на вкладке Общие в поле Отображаемое имя * (рис. 4), а также в веб-приложении .

Рис. 4. Дизайнер ELMA. Вкладка "Объекты". Режим отображения "Отображаемое имя"

Имя класса – уникальное имя объекта и/или перечисления, задаваемое латинскими символами и отображаемое в списке объектов в Дизайнере ELMA, в карточке объекта и/или перечисления на вкладке Общие в поле Имя класса * (рис. 5).

Рис. 5. Дизайнер ELMA. Вкладка "Объекты". Режим отображения "Имя класса"

Особенности отображения объектов и перечислений

Названия объектов и перечислений имеют следующие цветовые и графические обозначения:

Кнопки верхней панели инструментов