Вопрос 28 (1)
Домен ( Domain - доменное имя ) - В сети Internet - область пространства иерархических имён , которая обозначается уникальным доменным именем, обслуживается набором серверов доменных имён (DNS) и централизованно администрируется Администратором домена. Для каждого зарегистрированного доменного имени определен единственный Администратор.Доменное имя дает возможность обращаться к компьютеру по имени типа www.company.com, вместо запоминания его числового эквивалента.
Домен первого уровня (доменная зона, зона) - по международному соглашению каждой стране выделено некоторое кодовое обозначение длиной 2-3 буквы, которое называется доменом первого уровня или доменом этой страны. Так, например, если адрес сайта заканчивается на .ru - значит, сайт находится в домене России, .fr - Франции, .jp - Японии. Кроме того, существуют несколько доменов первого уровня, связанных не с географией, а с направленностью сайта - например, .com для коммерческих, .org для некоммерческих, .edu для образовательных организаций.
Синонимы термина Домен первого уровня - домен верхнего уровня, доменная зона, зона, Top-Level Domain, TLD.
Домен второго уровня - домены второго уровня выдаются предприятиям и частным лицам в аренду, как правило, с ежегодной оплатой. В каждой зоне домены второго уровня выдает специально уполномоченная организация. В России этим занимается РосНИИРОС. Домен второго уровня, также как и любого другого, должен состоять из цифр и букв латинского алфавита, например yahoo.com, lib.ru, b2b.ru. Выбирая домен второго уровня для своего сайта, как правило, стараются найти слово, которое будет соответствовать названию организации, товара или направления деятельности, а также легко читаться и запоминаться, например, gazeta.ru, generalmotors.ru, narod.ru.
Обладатель домена второго уровня имеет возможность создавать неограниченное количество доменных адресов третьего и далее уровней. Так, например, владелец домена pupkin.ru может создать для себя домены третьего уровня vasya.pupkin.ru, а для своей собаки - sharik.pupkin.ru.
Вопрос 28 (2)
Процесс выполнения операторов SQL
- На первом этапе выполняется синтаксический анализ оператора SQL. На этом этапе проверяется корректность записи SQL-оператора в соответствии с правилами синтаксиса.
- На этом этапе проверяется корректность параметров оператора SQL: имен отношений, имен полей данных, привилегий пользователя по работе с указанными объектами. Здесь обнаруживаются семантические ошибки.
- На этом этапе проводится оптимизация запроса. СУБД проводит разделение целостного запроса на ряд минимальных операций и оптимизирует последовательность их выполнения с точки зрения стоимости выполнения запроса. На этом этапе строится несколько планов выполнения запроса и выбирается из них один — оптимальный для данного состояния БД.
- На четвертом этапе СУБД генерирует двоичную версию оптимального плана запроса, подготовленного на этапе 3. Двоичный план выполнения запроса в СУБД фактически является эквивалентом объектного кода программы.
- И наконец, только на пятом этапе СУБД реализует (выполняет) разработанный план, тем самым выполняя оператор SQL.
Следует отметить, что перечисленные этапы отличаются по числу обращений к БД и по процессорному времени, требуемому для их выполнения. Синтаксический анализ проводится очень быстро, он не требует обращения к системным каталогам БД. Семантический анализ уже требует работы с базой метаданных, то есть с системными каталогами БД, поэтому при выполнении этого этапа происходит обращение к системному каталогу и серьезная работа с ним. Этап, связанный с оптимизаций плана запроса, требует работы не только с системным каталогом, но и со статистической информацией о БД, которая характеризует текущее состояние всех отношений, используемых в запросе, их физическое расположение на страницах и сегментах внешней памяти. В силу указанных причин этап оптимизации наиболее трудоемкий и длительный в процессе выполнения запроса. Однако если не проводить этап оптимизации, то стоимость (время) выполнения неоптимизированного запроса может в несколько раз превысить стоимость оптимизированного запроса. Время, потраченное на оптимизацию запроса, с лихвой компенсирует затраты на выполнение неоптимизированного запроса.
Этапы выполнения операторов SQL одни и те же как в интерактивном режиме, так и внутри приложений. Однако при работе с готовым приложением многие этапы СУБД может выполнить заранее.
Особенности встроенного SQL
При объединении операторов SQL c базовым языком программирования должны соблюдаться следующие принципы:
- Операторы SQL включаются непосредственно в текст программы на исходном языке программирования. Исходная программа поступает на вход препроцессора SQL, который компилирует операторы SQL.
- Встроенные операторы SQL могут ссылаться на переменные базового языка программирования.
- Встроенные операторы SQL получают результаты SQL-запросов с помощью переменных базового языка программирования.
- Для присвоения неопределенных значений ( NULL ) атрибутам отношений БД используются специальные функции.
- Для обеспечения построчной обработки результатов запросов во встроенный SQL добавляются несколько новых операторов, которые отсутствуют в интерактивном SQL.
Операторы манипулирования данными не требуют изменения для их встраивания в программный SQL. Однако оператор поиска ( SELECT ) потребовал изменений.
Стандартный оператор SELECT возвращает набор данных, подходящий сформированным условиям запроса. В интерактивном SQL этот полученный набор данных просто выводится на консоль пользователя и он может просмотреть полученные результаты. Встроенный оператор SELECT должен создавать структуры данных, которые согласуются с базовыми языками программирования. Во встроенном SQL запросы делятся на 2 типа:
- Однострочные запросы, где ожидаемые результаты соответствуют одной строке данных. Эта строка может содержать значения нескольких столбцов.
- Многострочные запросы, результатом которых является получение целого набора строк. При этом приложение должно иметь возможность проработать все полученные строки. Значит, должен существовать механизм, который поддерживает просмотр и обработку полученного набора строк.
Вопрос 29 (1)
Дедуктивные базы данных
По определению, дедуктивная БД состоит из двух частей: экстенциональной, содержащей факты, и интенциональной, содержащей правила для логического вывода новых фактов на основе экстенциональной части и запроса пользователя.
Легко видеть, что при таком общем определении SQL-ориентированную реляционную СУБД можно отнести к дедуктивным системам. Действительно, что есть определенные в схеме реляционной БД представления, как не интенциональная часть БД. В конце концов не так уж важно, какой конкретный механизм используется для вывода новых фактов на основе существующих. В случае SQL основным элементом определения представления является оператор выборки языка SQL, что вполне естественно, поскольку результатом оператора выборки является порождаемая таблица. Обеспечивается и необходимая расширяемость, поскольку представления могут определяться не только над базовыми таблицами, но и над представлениями.
Основным отличием реальной дедуктивной СУБД от реляционной является то, что и правила интенциональной части БД, и запросы пользователей могут содержать рекурсию. Можно спорить о том, всегда ли хороша рекурсия. Однако возможность определения рекурсивных правил и запросов дает возможность простого решения в дедуктивных базах данных проблем, которые вызывают большие проблемы в реляционных системах (например, проблемы разборки сложной детали на примитивные составляющие). С другой стороны, именно возможность рекурсии делает реализацию дедуктивной СУБД очень сложной и во многих случаях неразрешимой эффективно проблемой.
Мы не будем здесь более подробно рассматривать конкретные проблемы, применяемые ограничения и используемые методы в дедуктивных системах. Отметим лишь, что обычно языки запросов и определения интенциональной части БД являются логическими (поэтому дедуктивные БД часто называют логическими). Имеется прямая связь дедуктивных БД с базами знаний (интенциональную часть БД можно рассматривать как БЗ). Более того, трудно провести грань между этими двумя сущностями; по крайней мере, общего мнения по этому поводу не существует.
Какова же связь дедуктивных БД с реляционными СУБД, кроме того, что реляционная БД является вырожденным частным случаем дедуктивной? Основным является то, что для реализации дедуктивной СУБД обычно применяется реляционная система. Такая система выступает в роли хранителя фактов и исполнителя запросов, поступающих с уровня дедуктивной СУБД. Между прочим, такое использование реляционных СУБД резко актуализирует задачу глобальной оптимизации запросов.
При обычном применении реляционной СУБД запросы обычно поступают на обработку по одному, поэтому нет повода для их глобальной (межзапросной) оптимизации. Дедуктивная же СУБД при выполнении одного запроса пользователя в общем случае генерирует пакет запросов к реляционной СУБД, которые могут оптимизироваться совместно.
Конечно, в случае, когда набор правил дедуктивной БД становится велик, и их невозможно разместить в оперативной памяти, возникает проблема управления их хранением и доступом к ним во внешней памяти. Здесь опять же может быть применена реляционная система, но уже не слишком эффективно. Требуются более сложные структуры данных и другие условия выборки. Известны частные попытки решить эту проблему, но общего решения пока нет.
Вопрос 29 (2)
В системах компьютерной безопасности, контролем доступа на основе ролей (RBAC, - role-based access control) называется способ построения систем разграничения доступа авторизованных пользователей. С недавних пор он является альтернативой мандатному контролю доступа (MAC, - mandatory access control) и дискреционному контролю доступа(DAC, - discretionary access control).
Технология контроля доступа RBAC достаточно гибка и сильна, чтобы смоделировать как дискреционный контроль доступа (DAC), так и мандатный контроль доступа (MAC).
До разработки RBAC, единственными известными моделями контроля доступа были MAC и DAC: если модель была не MAC, то она была DAC, и наоборот. Исследования в 90-х показали, что RBAC не попадает ни в ту, ни в другую категорию.
Роли создаются внутри организации для различных рабочих функций. Определенным ролям присваиваются полномочия ('permissions') для выполнения тех или иных операций. Штатным сотрудникам (или другим пользователям системы) назначаются фиксированные роли, через которые они получают соответствующие привилегии для выполнения фиксированных системных функций. В отличие отконтроля доступа на основе контекста (CBAC, - context-based access control), RBAC не принимает во внимание текущую ситуацию (такую как, например, откуда было установлено соединение).
Так как привилегии не назначаются пользователям непосредственно, и приобретаются ими только через свою роль (или роли), управление индивидуальными правами пользователя по сути превращается в простое присвоение ему ролей. Это упрощает общие операции, такие как добавление пользователя или смена подразделения пользователем.
RBAC отличается от списков контроля доступа(ACL, - access control lists), используемых в традиционных дискреционных системах контроля доступа, тем что может присваивать привилегии на сложные операции с составными данными, а не только на атомарные операции с низкоуровневыми объектами данных. Например, лист контроля доступа может предоставить или лишить права записи в такой-то системный файл, но он не может сказать, каким образом этот файл может быть изменен. Система, основанная на RBAC, позволяет создать такую операцию как открытие 'кредита' в финансовом приложении или заполнение записи 'тест на уровень сахара в крови' в медицинском приложении. Присвоение привилегии на выполнение такой-то операции многозначно, так как операции являются дробящимися в пределах приложения.
Концепции иерархии ролей и ограничений позволяют создать или смоделировать контроль доступа на основе решетки (LBAC, - lattice-based access control) средствами RBAC. Таким образом, RBAC может быть основанием и расширением LBAC.
Для определения модели RBAC используются следующие соглашения:
S = Субъект (Subject) = Человек или автоматизированный агент
R = Роль (Role) = Рабочая функция или название, которое определяется на уровне авторизации
P = Разрешения (Permissions) = Утверждения режима доступа к ресурсу
SE = Сессия (Session) = Соответствие между S, R и/или P
SA = Назначение субъекта (Subject Assignment)
PA = Назначение разрешения (Permission Assignment)
RH = Частично упорядоченная иерархия ролей (Role Hierarchy). RH может быть еще записана так: ≥
Один субъект может иметь несколько ролей.
Одну роль могут иметь несколько субъектов.
Одна роль может иметь несколько разрешений.
Одно разрешение может принадлежать нескольким ролям.
Вопрос 30 (1)
Информационная модель– модель объекта, представленная в виде информации, описывающей существенные для данного рассмотрения параметры и переменные величины объекта, связи между ними, входы и выходы объекта, и позволяющая путем подачи на модель информации об изменениях входных величин моделировать возможные состояния объекта.
Информационные модели нельзя потрогать или увидеть, она не имеют материального воплощения, потому что строятся только на информации. Информационная модель – совокупность информации, характеризующая существенные свойства и состояния объекта, процесса, явления, а также взаимосвязь с внешним миром.
Информационная модель – формальная модель ограниченного набора фактов, понятий или инструкций, предназначенная для удовлетворения конкретному требованию.
Для построения информационной модели необходимо пройти ряд стадий, представленных на схеме 3. Процесс, проводимый от «объекта познания» жл «формальной конструкции», носит название «формализация», а обратный процесс – «интерпретация» - чаще всего используется в познании мира и обучении.
В основе информационного моделирования лежат три постулата:
- все состоит из элементов;
- элементы имеют свойства;
- элементы связаны между собой отношениями.
Объект, к которому применимы эти постулаты, может быть представлен информационной моделью.
Классификации информационных моделей:
-по способу описания:
- с помощью формальных языков (язык математики, таблицы, языки программирования, расширение естественного языка человека и т.д.);
- графические (блок-схемы, диаграммы, графики и т.д.).
-по цели создания:
- классификационное (древовидные, генеалогическое дерево, дерево каталогов в компьютере);
- динамические (как правило, строятся на основе решения дифференциальных уравнений и служат для решения задач управления и прогнозирования).
- по природе моделируемого объекта:
- детерминированные (определенные), для которых известны законы, по которым изменяется или развивается объект;
- вероятностные (обработка статистической неопределенности и некоторых видов нечеткой информации).
Вопрос 30 (2)
В настоящее время экспертные системы используются для решения различных типов задач в самых разнообразных проблемных областях, таких, как финансы, нефтяная и газовая промышленность, энергетика, транспорт, фармацевтическое производство, космос, химия, образование, телекоммуникации и связь и др. Рассмотрим наиболее яркие примеры экспертных систем.
Примеры экспертных систем в военном деле
ACES. Экспертная система выполняет картографические работы по нанесению обстановки на карты. Система получает в качестве исходных данных карту без обстановки и информацию, описывающую расположение объектов на местности. Система выдает карту, содержащую все желаемые условные обозначения и подписи, размещенные без взаимного наложения. ACES применяет объектно-ориентированную схему представления знаний и реализована на языке Loops для работы на АРМ Xerox Dolphin. Система разработана компанией ESL и доведена до уровня исследовательского прототипа.
ASTA. Экспертная система помогает аналитику определить тип радара, пославшего перехваченный сигнал. Система анализирует этот сигнал в свете имеющихся у нее общих знаний о физике радаров и специальных знаний о конкретных типах радарных систем. ASTA также помогает аналитику, обеспечивая ему доступ к соответствующим базам данных и давая объяснения своим заключениям. Знания в системе представлены в виде правил. Эта система разработана компанией Advanced Information & Decision Systems и доведена до уровня исследовательского прототипа.
DART. Экспертная система помогает обрабатывать разведданные о центрах командования, управления и связи противника. Она дает советы аналитикам по идентификации критических узлов сети командования, управления и связи и помогает обрабатывать сообщения о боевой обстановке. Система DART реализована на языках Паскаль и Си для компьютерных систем VAX 11/780. Она разработана компанией «Par Technology Corporation» и доведена до уровня исследовательского прототипа.
HANNIBAL. Экспертная система выполняет оценивание ситуаций в области разведки радиообмена противника. Система идентифицирует соединения противника и боевой порядок их связи, интерпретируя данные радиоперехвата. Эти данные включают информацию о местонахождении и характеристиках сигналов (частоте, модуляции, классе канала и другие) обнаруженных средств связи. Знания в системе представлены в рамках архитектуры доски объявлений, координирующей деятельность нескольких специалистов, или источников знаний. Система реализована с помощью средств AGE. Она разработана компанией ESL и доведена до уровня исследовательского прототипа.
I&W. Экспертная система помогает аналитикам из разведки предсказывать, когда и где произойдет следующее вооруженное столкновение. Система анализирует поступающие сообщения разведки, например донесения о местонахождении воинских соединений, их деятельности и передвижениях, применяя знания об обычных признаках активности войск. Знания представлены в рамках архитектуры доски объявлений, в которой для обеспечения компетентности применены как правила с прямой цепочкой рассуждений, так и фреймы. Система реализована на языке INTERLISP-D для АРМ Xerox 1100. Она разработана компанией ESL в сотрудничестве со Стенфордским университетом и доведена до уровня демонстрационного прототипа.
RUBRIC. Экспертная система помогает пользователю получить доступ к базам данных, содержащим неформатированные тексты. Например, когда пользователь называет какую-нибудь тему, RUBRIC автоматически разыскивает все документы, содержащие тексты, связанные с этой темой. В системе RUBRIC взаимоотношения между темами, подтемами и фразами, содержащими ключевые слова, выражены в виде правил. Правила также определяют другие варианты терминов, выражений и способов написания одной и той же темы или понятия. Пользователь может сформулировать запрос в виде правила, задающего критерий поиска, например эвристический вес, определяющий насколько сильно образец правила указывает на наличие темы правила. В ходе поиска RUBRIC предоставляет пользователю документы, которые лежат в кластере, содержащем по крайней мере один документ с весом выше заданного пользователем порога. Это предотвращает ситуацию, в которой произвольно выбранный порог мог бы разделить близкие по рангу документы. Система реализована на языке FRANZ LISP, разработана компанией «Advanced Information & Decision Systems» и доведена до уровня исследовательского прототипа.
Пример экспертной системы в информатике
CODES. Экспертная система помогает разработчику базы данных, желающему использовать подход IDEF1 для определения концептуальной схемы базы данных. Хотя в качестве подхода IDEF1 полезна, сложность ее правил часто сдерживает ее применение. Разработчик описывает, какие свойства и взаимосвязи желательны в базе данных, под руководством системы CODES, осуществляемым в форме диалога. Затем система применяет свои знания в виде правил и эвристик IDEF1 для построения концептуальной схемы разрабатываемой базы данных. Знания в CODES представлены в виде правил с применением обратной цепочки рассуждений в качестве стратегии управления. CODES реализована на языке UCI LISP. Она была разработана в Университете штата Южная Калифорния и доведена до уровня демонстрационного прототипа.
Пример экспертной системы в компьютерных системах
MIXER. Экспертная система оказывает помощь программистам в написании микропрограмм для разработанной Texas Instruments СБИС TI990. По заданному описанию микропрограммы система получает оптимизированные микропрограммы для TI990. MIXER содержит знания по микропрограммированию для TI990, взятые из руководства и из анализа микропрограммы управляющего ПЗУ TI990. Сюда относятся знания о том, как преобразовывать введенные описания в наборы промежуточных операций, как выделить соответствующие регистры под переменные и как преобразовать промежуточные операции в наборы микроопераций. MIXER использует эти знания, чтобы определить, какие микрооперации являются лучшими для реализации микропрограммы. Система представляет знания в виде правил и данных, обладает унификацией, управляемой механизмом вывода, и динамическим возвратом. MIXER реализована на языке Пролог. Она была разработана в Токийском университете и доведена до уровня демонстрационного прототипа.
Пример экспертной системы в электронике
ACE. Экспертная система определяет неисправности в телефонной сети и дает рекомендации по необходимому ремонту и восстановительным мероприятиям. Система работает без вмешательства пользователя, анализируя сводки-отчеты о состоянии, получаемые ежедневно с помощью CRAS, программы, следящей за ходом ремонтных работ в кабельной сети. ACE обнаруживает неисправные телефонные кабели и затем решает, нуждаются ли они в планово-предупредительном ремонте и выбирает, какой тип ремонтных работ вероятнее всего будет эффективным. Затем ACE запоминает свои рекомендации в специальной базе данных, к которой у пользователя есть доступ. Система принимает решения, применяя знания относительно телефонных станций, сообщения системы CRAS и стратегии анализа сетей. Представление знаний в системе основано на правилах, используется схема управления посредством прямой цепочки рассуждений. АСЕ реализована на языках OPS4 и FRANZ LISP и работает на микропроцессорах серии AT&T 3B-2, размещенных в подстанциях наблюдения состояния кабеля. Она разработана в Bell Laboratories. АСЕ прошла опытную эксплуатацию и доведена до уровня коммерческой экспертной системы.
