http://www.relcom.ru/Internet/Literature/index.html 1 страница

148 КОММУТАЦИЯ КАНАЛОВ В СЕТЯХ: СУЩНОСТЬ, ОЦЕНКА, ОБЛАСТЬ ПРИМЕНЕНИЯ

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

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

Достоинства коммутации каналов:

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

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

Недостатки коммутации каналов

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

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

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

149 КОММУТАЦИЯ ПАКЕТОВ В СЕТЯХ: СУЩНОСТЬ, ОЦЕНКА, ОБЛАСТЬ ПРИМЕНЕНИЯ

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

Достоинства коммутации пакетов

Высокая общая пропускная способность сети при передаче пульсирующего трафика.

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

Недостатки коммутации пакетов

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

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

Возможные потери данных из-за переполнения буферов.

130 Использование нормальных форм при проектировании БД. Примеры.

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

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

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

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

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

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

Отношение находится в 4НФ, если оно находится в НФБК и в нем отсутствуют многозначные зависимости, не являющиеся функциональными.

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

Пример приведения таблицы к третьей нормальной форме

Исходная таблица:

ФамилияОтдел Телефон
Гришин Бухгалтерия 11-22-33
Васильев Бухгалтерия 11-22-33
Петров Снабжение 44-55-66

В результате приведения к 3НФ получаются две таблицы:
ОтделНаименование отделаТелефон
1 Бухгалтерия 11-22-33
2 Снабжение 44-55-66

Фамилия Отдел
Гришин 1
Васильев 1
Петров 2

101 Показатели эффективности функционирования ОС.

Эффективность – степень соответствия своему назначению, техническое совершенство и экономическая целесообразность

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

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

Предсказуемость

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

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

Совместимость. Существует несколько «долгоживущих» популярных ОС (разновидности UNIX, MS-DOS, Windows 3.x, Windows NT, OS/2), для которых наработана широкая номенклатура приложений. Поэтому для пользователя, переходящего по тем или иным причинам с одной ОС на другую, очень привлекательна возможность запуска в новой ОС привычного приложения. Если ОС имеет средства для выполнения прикладных программ, написанных для других ОС, то про неё говорят, что она обладает совместимостью с этими ОС.

Удобство

Масштабируемость

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

123 Характеристика реляционной модели данных. Примеры

Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии отношение (relation).

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

Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам - атрибуты отношения.

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

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

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

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

Примерами зарубежных реляционных СУБД для ПЭВМ являются следующие: DBaseIII Plus и dBase IY (фирма Ashton-Tate), DB2 (IBM), R:BASE (Microrim), FoxFro ранних версий и EoxBase (Fox Software), Раrаdох и dBASE for Windows (Borland), FoxFro более поздних версий, Visual FoxFro и Access (Microsoft), Clarion (Clarion Software), Ingres (ASK Computer Systems) и Oracle (Oracle).

К отечественным СУБД реляционного типа относятся системы: ПАЛЬМА (ИК АН УССР), а также система HyTech (МИФИ).

Заметим, что последние версии реляционных СУБД имеют некоторые свойства объектно-ориентированных систем. Такие СУБД часто называют объектно-реляционными. Примером такой системы можно считать продукты Oracle 8.х. Системы предыдущих версий вплоть до Oracle 7.х считаются «чисто» реляционными.

119 Назначение и компоненты хранилища данных

Хранилища данных – это процесс сбора, отсеивания и предварительной обработки данных с целью представления результирующей информации пользователям для статистического анализа и аналитических отчетов. Ральф Кинболл (автор концепции хранилищ данных) описывал хранилища данных как «место, где люди могут получить доступ к своим данным». Он же сформулировал основные требования к хранилищам данных:

– поддержка высокой скорости данных из хранилища;

– поддержка внутренней непротиворечивости данных;

– возможность получения и сравнения данных;

– наличие удобных утилит просмотра данных хранилища;

– полнота и достоверность хранимых данных;

– поддержка качественного процесса пополнения данных.

Всем перечисленным требованиям удовлетворять зачастую не удается, поэтому для реализации хранилищ данных используют несколько продуктов. Одни из которых представляют средства хранения данных, другие – средства их извлечения и просмотра, в-третьих – средства пополнения хранилищ данных. Типичное хранилище данных как правило отличается от реляционной базы данных: 1) Обычная база данных предназначена для того, чтобы помочь пользователям выполнять повседневную работу, тогда как хранилища данных предназначены для принятия решений; 2) Обычная база данных подвержена постоянным изменениям в процессе работы пользователей, а хранилища данных относительно стабильно; данные в нем обновляются согласно расписанию (например, ежечасно, ежедневно, ежемесячно), в идеале, процесс пополнения данными за определенный период времени без изменения прежней информации находящейся уже в хранилище. 3) Обычная база данных чаще всего является источником данных попадающих в хранилище, кроме того хранилище может пополняться за счет внешних источников (например, сжатия данных).

Использование технологии хранилищ данных предполагает наличие в системе следующих компонентов:

– оперативных источников данных;

– средств переноса и трансформации данных;

– метаданных – включают каталог хранилища и правила преобразования данных при загрузке их из оперативных баз данных;

– реляционного хранилища;

– OLAP хранилища;

– средств доступа и анализа данных.

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

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

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

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

132 Характеристика CASE-средств и CASE-технологий. Примеры

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

Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.

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

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

методология (MethodDiagrams), которая задает единый графический язык и правила работы с ним.

графические редакторы (GraphicEditors), которые помогают рисовать диаграммы; возникли с распространением PC и GUI, так называемых «uppercase технологий

генератор: по графическому представлению модели можно сгенерировать исходный код для различных платформ (так называемая lowcase часть CASE-технологии).

репозиторий, своеобразная база данных для хранения результатов работы программистов. [11]

^ 3. Внедрение CASE-технологий.

Приведенная в данном разделе технология базируется в основном на стандартах IEEE [16,17] (IEEE - Institute of Electrical and Electronics Engineers - Институт инженеров по электротехнике и электронике). Термин «внедрение» используется в широком смысле и включает все действия от оценки первоначальных потребностей до полномасштабного использования CASE-средств в различных подразделениях организации-пользователя. Процесс внедрения CASE-средств состоит из следующих этапов:

определение потребностей в CASE-средствах;

оценка и выбор CASE-средств;

выполнение пилотного проекта;

практическое внедрение CASE-средств. [6]

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

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

118 Основные средства разработки БД

ER-модели широко используются в практике создания БД. Они применяются при ручном и автоматизированном проектировании с использованием CASE-средств, поддерживающих весь цикл разработки СБД или отдельные его стадии. Ктаким средствам относятся: ProKit*WORKBENCH, Design / IDEF, CASE Oracle (Designer / 2000), Power Designer (S-Designor), ERWin, SILVERRUN, ERStudio и другие. CASE-средства являются сравнительно новым направлением в информационных технологиях. Первая версия инструментария Oracle появилась в 1989 г.

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

При сравнении CASE-систем кроме используемой методологии ER-моделирования, необходимо учитывать специфические критерии, связанные с реализацией функций автоматизированного проектирования:

· число и перечень поддерживаемых целевых СУБД;

· поддержку распределенных БД;

· поддержку коллективной работы при проектировании (управление правами пользователей, ведение репозитория и т. д.);

· построение концептуальной ER-модели по описанию структуры существующей БД – реверс-инжиниринг;

· автоматизируемые функции проектирования и степень их автоматизации;

· качество и жесткость проектных решений (возможность выбора из нескольких альтернативных решений, возможность ручного вмешательства в процесс);

· надежность работы;

· документирование проекта;

· открытость системы (возможность стыковки с другими средствами);

· удобство графического редактора;

· количественные ограничения (общее число сущностей, число уровней вложенности для обобщенной сущности и др.);

· возможность автоматической оценки объема памяти для проектируемой БД;

· возможность автоматической генерации процедур;

· наличие средств моделирования хранилищ данных;

· требования к ресурсам компьютера;

· операционную среду;

· стоимость системы.

CASE-средства показывают модель с разной степенью детализации:

· только обозначения сущностей и связей между ними;

· сущности + ключи;

· сущности + ключи + внешние ключи;

· сущности + все атрибуты.

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

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

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

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

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

Многие CASE-средства позволяют экспортировать модели в другие системы и, наоборот, импортировать их из других систем.

122 Характеристика сетевой модели данных. Примеры

Сетевая модель данных позволяет отображать разнообразные взаимосвязи элементов данных в виде произвольного графа, обобщая тем самым иерархическую модель данных (рис. 4.). Наиболее полно концепция сетевых БД впервые была изложена в Предложениях группы КОДАСИЛ (KODASYL). (см. Приложение рис.4.) Для описания схемы сетевой БД используется две группы типов: «запись» и «связь». Тип «связь» определяется для двух типов «запись»: предка и потомка. Переменная типа «связь» являются экземплярами связей. Сетевая БД состоит из набора записей и набора соответствующих связей. На формирование связи особых ограничений не накладывается. Если в иерархических структурах запись-потомок могла иметь только одну запись-предка, то в сетевой модели данных запись-потомок может иметь произвольное число записей-предков (сводных родителей). Пример схемы простейшей сетевой БД показан на рис.5. Типы связей здесь обозначены надписями на соединяющих типы записей линиях. (см. Приложение рис.5.) B различных СУБД сетевого типа для обозначения одинаковых по сути понятий зачастую используются различные термины. Например, такие как элементы и агрегаты данных, записи, наборы, области и т. д.

Дата публикования: 2015-01-26; Прочитано: 413 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!