Автоматизированная система управления

Лекция 1 ВВОДНАЯ ЛЕКЦИЯ Первоначально развитие промышленных установок и производственных процессов происходило параллельно развитию автоматики, которая приспосабливалась к существующим условиям работы автоматизируемых объектов. При этом создавались автоматические системы регулирования отдельных простейших устройств (частичная автоматизация), которые в ряде случаев оказывались мало эффективными. В последующий период решалась задача комплексной автоматизации производственных и технологических процессов, а также промышленных и транспортных установок в целом. Развитие комплексной автоматизации основывается на переходе к новым, более совершенным технологическим процессам в непрерывно-поточной форме. Широко применяются автоматические приборы и устройства, заменяющие труд человека в управлении технологическими процессами и техническими устройствами. Выдвигаются принципиально новые требования к автоматизации промышленных установок и технологических процессов, обусловливающие разработку автоматизированных систем управления технологическими процессами (АСУ ТП) в целом. Технический прогресс в развитии промышленности и исследовании космоса поставил задачу создания систем исключительно высокой точности и минимальной сложности. Такие автоматические системы должны без участия оператора находить условия высокоэффективного ведения процесса в данной обстановке. В связи с этим дальнейшее развитие теории и практики автоматического управления связано с выявлением предельных возможностей систем и построением систем, наилучших (оптимальных) по какому-либо технико-экономическому показателю. К понятию оптимальности естественно приходят, пытаясь решить какую-либо задачу при определенных условиях наилучшим образом. Принципы оптимального управления используют в технике, экономике, военном деле и других областях. Применение принципа оптимальности в технике позволяет осуществить оптимальное управление различными техническими устройствами и технологическими процессами, т. е. для заданного объекта управления и условий его работы обеспечить наилучшие показатели качества, характеризующие режим его работы. Оптимальное управление широко используется в период комплексной автоматизации технологических и производственных процессов или сложных технических устройств. При этом рассматривается задача оптимизации режимов с учетом ограничений, определяемых условиями работы объекта управления, для детерминированных и случайных сигналов как при неизменных, так и изменяющихся параметрах и характеристиках объекта управления и сигналов внешних воздействий. Теория оптимального быстродействия впервые была изложена в трудах А.А.Фельдбаума, который в 1953–1956 гг. ввел понятие оптимальных по быстродействию процессов. В этот же период Я.З.Цыпкин рассмотрел вопрос об определении моментов переключения реле для оптимальных процессов в релейных системах. Основные результаты по разработке оптимальных по быстродействию систем при комплексно-сопряженных корнях характеристического уравнения объектов второго порядка получены американским математиком Бушау. Акад.Л.С.Понтрягин сформулировал в 1956 г. принцип максимума, являющийся единым математическим аппаратом теории оптимальных по быстродействию процессов для систем n-го порядка с несколькими управляющими органами в случае ограниченных по модулю координат управления. В 1961–1962 гг. Н. Н. Красовским и А. М. Летовым была разработана теория аналитического конструирования оптимальных регуляторов, применение которой позволяет проектировать оптимальные по точности системы. В период 1940–1965 гг. Н. Винером, Р. Калманом и Р. Бьюси создана теория оптимальных систем при случайных сигналах. Дальнейшее развитие теория и практика оптимальных систем получили в трудах В.Г.Болтянского, Р.В.Гамкрелидзе, С.В.Емельянова, В.И.Зубова, Н.Н.Красовского, А.М.Летова, Б.Н.Петрова, В.М.Пономарева, Е.П.Попова, А.В.Репникова, Л.И.Розоноэра, В.В.Солодовникова, М.Е.Салуквадзе, Я.З.Цыпкина и др., а также в трудах зарубежных ученых– М.Атанса, Р.Беллмана, Н.Винера, Р.Калмана, Б. Куо, М.Фалба и др. Задачи дальнейшего совершенствования систем управления технологическими и производственными процессами, а также сложными техническими устройствами требуют увеличения объема информации, необходимой для функционирования систем управления. Если параметры и характеристики объекта управления не являются стабильными, а статистические характеристики сигналов внешних воздействий изменяются произвольно, то неизменная (жесткая) настройка оптимальных систем по начальной информации не позволяет обеспечить оптимальные процессы из-за недостаточности информации. Для повышения качества управления объектами при неполной информации (в условиях неопределенности) применяют принцип адаптации. Первые разработки автоматических систем, обладающих свойствами оптимальности и адаптации, обусловлены созданием экстремальных автоматических систем. В настоящее время теория и практика экстремальных систем достигли значительных успехов. Промышленностью выпускаются типовые экстремальные регуляторы (оптимизаторы), существенно улучшающие технико-экономические показатели производственных и технологических процессов. При дальнейшем совершенствовании автоматических систем, обладающих свойствами адаптации, предусматривается разработка адаптивных систем, обеспечивающих самонастройку параметров или структуры регулятора и обладающих свойствами самообучения в зависимости от условий функционирования. Применение принципов оптимальности и адаптации в технике позволяет создавать наиболее совершенные автоматические системы, обладающие высоким качеством функционирования в реальных условиях, такие, как обучающиеся автоматические системы и биокибернетические системы. Лекция 2 Автоматизированная система управления Автоматизированная система управления или АСУ — комплекс аппаратных и программных средств, предназначенный для управления различными процессами в рамках технологического процесса, производства, предприятия. АСУ применяются в различных отраслях промышленности, энергетике, транспорте и т. п. Термин автоматизированная, в отличие от термина автоматическая подчёркивает сохранение за человеком-оператором некоторых функций, либо наиболее общего, целеполагающего характера, либо не поддающихся автоматизации. АСУ с Системой поддержки принятия решений (СППР), являются основным инструментом повышения обоснованности управленческих решений. Создателем первых АСУ в СССР является доктор экономических наук, профессор, член-корреспондент Национальной академии наук Белоруссии, основоположник научной школы стратегического планирования Николай Иванович Ведута (1913—1998). В 1962—1967 гг. в должности директора Центрального научноисследовательского института технического управления (ЦНИИТУ), являясь также членом коллегии Министерства приборостроения СССР, он руководил внедрением первых в стране автоматизированных систем управления производством на машиностроительных предприятиях. Активно боролся против идеологических PR-акций по внедрению дорогостоящих ЭВМ, вместо создания настоящих АСУ для повышения эффективности управления производством. Важнейшая задача АСУ — повышение эффективности управления объектом на основе роста производительности труда и совершенствования методов планирования процесса управления. Различают автоматизированные системы управления объектами (технологическими процессами — АСУТП, предприятием — АСУП, отраслью — ОАСУ) и функциональные автоматизированные системы, например, проектирование плановых расчётов, материально-технического снабжения и т.д. Цели автоматизации управления В общем случае, систему управления можно рассматривать в виде совокупности взаимосвязанных управленческих процессов и объектов. Обобщенной целью автоматизации управления является повышение эффективности использования потенциальных возможностей объекта управления. Таким образом, можно выделить ряд целей: 1. Предоставление лицу, принимающему решение (ЛПР) релевантных данных для принятия решений 2. Ускорение выполнения отдельных операций по сбору и обработке данных 3. Снижение количества решений, которые должно принимать ЛПР 4. Повышение уровня контроля и исполнительской дисциплины 5. Повышение оперативности управления 6. Снижение затрат ЛПР на выполнение вспомогательных процессов 7. Повышение степени обоснованности принимаемых решений Состав АСУ В состав АСУ входят следующие виды обеспечений: информационное, программное, техническое, организационное, метрологическое, правовое и лингвистическое. Основные классификационные признаки Основными классификационными признаками, определяющими вид АСУ, являются:  сфера функционирования объекта управления (промышленность, строительство, транспорт, сельское хозяйство, непромышленная сфера и т.д.)  вид управляемого процесса (технологический, организационный, экономический и т.д.);  уровень в системе государственного управления, включения управление народным хозяйством в соответствии с действующими схемами управления отраслями (для промышленности: отрасль (министерство), всесоюзное объединение, всесоюзное промышленное объединение, научно-производственное объединение, предприятие (организация), производство, цех, участок, технологический агрегат). Функции АСУ Функции АСУ устанавливают в техническом задании на создание конкретной АСУ на основе анализа целей управления, заданных ресурсов для их достижения, ожидаемого эффекта от автоматизации и в соответствии со стандартами, распространяющимися на данный вид АСУ. Каждая функция АСУ реализуется совокупностью комплексов задач, отдельных задач и операций. Функции АСУ в общем случае включают в себя следующие элементы (действия):  планирование и (или) прогнозирование;  учет, контроль, анализ;  координацию и (или) регулирование. Необходимый состав элементов выбирают в зависимости от вида конкретной АСУ. Функции АСУ можно объединять в подсистемы по функциональному и другим признакам. Функции при формировании управляющих воздействий  Функции обработки информации (вычислительные функции) – осуществляют учет, контроль, хранение, поиск, отображение, тиражирование, преобразование формы информации;  Функции обмена (передачи) информации – связаны с доведением выработанных управляющих воздействий до ОУ и обменом информацией с ЛПР;  Группа функций принятия решения (преобразование содержания информации) – создание новой информации в ходе анализа, прогнозирования или оперативного управления объектом Классы структур АСУ В сфере промышленного производства с позиций управления можно выделить следующие основные классы структур систем управления: децентрализованную, централизованную, централизованную рассредоточенную и иерархическую. Децентрализованная структура Построение системы с такой структурой эффективно при автоматизации технологически независимых объектов управления по материальным, энергетическим, информационным и другим ресурсам. Такая система представляет собой совокупность нескольких независимых систем со своей информационной и алгоритмической базой. Для выработки управляющего воздействия на каждый объект управления необходима информация о состоянии только этого объекта. Централизованная структура Централизованная структура осуществляет реализацию всех процессов управления объектами в едином органе управления, который осуществляет сбор и обработку информации об управляемых объектах и на основе их анализа в соответствии с критериями системы вырабатывает управляющие сигналы. Появление этого класса структур связано с увеличением числа контролируемых, регулируемых и управляемых параметров и, как правило, с территориальной рассредоточенностью объекта управления. Достоинствами централизованной структуры являются достаточно простая реализация процессов информационного взаимодействия; принципиальная возможность оптимального управления системой в целом; достаточно легкая коррекция оперативно изменяемых входных параметров; возможность достижения максимальной эксплуатационной эффективности при минимальной избыточности технических средств управления. Недостатки централизованной структуры следующие: необходимость высокой надежности и производительности технических средств управления для достижения приемлемого качества управления; высокая суммарная протяженность каналов связи при наличии территориальной рассредоточенности объектов управления. Централизованная рассредоточенная структура Основная особенность данной структуры — сохранение принципа централизованного управления, т.е. выработка управляющих воздействий на каждый объект управления на основе информации о состояниях всей совокупности объектов управления. Некоторые функциональные устройства системы управления являются общими для всех каналов системы и с помощью коммутаторов подключаются к индивидуальным устройствам канала, образуя замкнутый контур управления. Алгоритм управления в этом случае состоит из совокупности взаимосвязанных алгоритмов управления объектами, которые реализуются совокупностью взаимно связанных органов управления. В процессе функционирования каждый управляющий орган производит прием и обработку соответствующей информации, а также выдачу управляющих сигналов на подчиненные объекты. Для реализации функций управления каждый локальный орган по мере необходимости вступает в процесс информационного взаимодействия с другими органами управления. Достоинства такой структуры: снижение требований, к производительности и надежности каждого центра обработки и управления без ущерба для качества управления; снижение суммарной протяженности каналов связи. Недостатки системы в следующем: усложнение информационных процессов в системе управления из-за необходимости обмена данными между центрами обработки и управления, а также корректировка хранимой информации; избыточность технических средств, предназначенных для обработки информации; сложность синхронизации процессов обмена информацией. Иерархическая структура С ростом числа задач управления в сложных системах значительно увеличивается объем переработанной информации и повышается сложность алгоритмов управления. В результате осуществлять управление централизованно невозможно, так как имеет место несоответствие между сложностью управляемого объекта и способностью любого управляющего органа получать и перерабатывать информацию. Кроме того, в таких системах можно выделить, следующие, группы задач, каждая из которых характеризуется соответствующими требованиями по времени реакции на события, происходящие в управляемом процессе: задачи сбора данных с объекта управления и прямого цифрового управления (время реакции , секунды, доли секунды); задачи экстремального управления, связанные с расчётами желаемых параметров управляемого процесса и требуемых значений уставок регуляторов, с логическими задачами пуска и остановки агрегатов и др. (время реакции — секунды, минуты); задачи оптимизации и адаптивного управления процессами, техникоэкономические задачи (время реакции — несколько секунд); информационные задачи для административного управления, задачи диспетчеризации и координации в масштабах цеха, предприятия, задачи планирования и др. (время реакции — часы). Очевидно, что иерархия задач управления приводит к необходимости создания иерархической системы средств управления. Такое разделение, позволяя справиться с информационными трудностями для каждого местного органа управления, порождает необходимость согласования принимаемых этими органами решений, т. е. создания над ними нового управляющего органа. На каждом уровне должно быть обеспечено максимальное соответствие характеристик технических средств заданному классу задач. Кроме того, многие производственные системы имеют собственную иерархию, возникающую под влиянием объективных тенденций научно-технического прогресса, концентрации и специализации производства, способствующих повышению эффективности общественного производства. Чаще всего иерархическая структура объекта управления не совпадает с иерархией системы управления. Следовательно, по мере роста сложности систем выстраивается иерархическая пирамида управления. Управляемые процессы в сложном объекте управления требуют своевременного формирования правильных решений, которые приводили бы к поставленным целям, принимались бы своевременно, были бы взаимно согласованы. Каждое такое решение требует постановки соответствующей задачи управления. Их совокупность образует иерархию задач управления, которая в ряде случаев значительно сложнее иерархии объекта управления. Виды АСУ  Автоматизированная система управления технологическим процессом или АСУ ТП — решает задачи оперативного управления и контроля техническими объектами в промышленности, энергетике, на транспорте  Автоматизированная система управления производством (АСУ П) — решает задачи организации производства, включая основные производственные процессы, входящую и исходящую логистику. Осуществляет краткосрочное планирование выпуска с учётом производственных мощностей, анализ качества продукции, моделирование производственного процесса. Для решения этих задач применяются MIS и MES-системы, а также LIMS-системы. Примеры: o Автоматизированная система управления уличным освещением («АСУ УО») — предназначена для организации автоматизации централизованного управления уличным освещением. o o  Автоматизированная система управления наружного освещения («АСУНО») — предназначена для организации автоматизации централизованного управления наружным освещением. Автоматизированная система управления дорожным движением или АСУ ДД — предназначена для управления транспортных средств и пешеходных потоков на дорожной сети города или автомагистрали Автоматизированная система управления предприятием или АСУП — Для решения этих задач применяются MRP,MRP II и ERP-системы. В случае, если предприятием является учебное заведение, применяются системы управления обучением. Примеры: o o «Система управления гостиницей». Наряду с этим названием употребляется PMS Property Management System «Автоматизированная система управления операционным риском» - это программное обеспечение, содержащее комплекс средств, необходимых для решения задач управления операционными рисками предприятий: от сбора данных до предоставления отчетности и построения прогнозов. Лекция 3 КЛАССИФИКАЦИЯ АСУ Для проведения классификации объектов и явлений необходимо в первую очередь сформулировать цель классификации и определить классификационные признаки. В работе [6] отмечается, что целью классификации АСУП является: описание внедренных и разрабатываемых АСУП с точностью, достаточной для перспективного плана развития работ по созданию АСУП; инвентаризация проектов АСУП, позволяющая систематизировать накопленный опыт разработки АСУП; создание исходной базы для определения требований и норм на стадиях проектирования функционирования АСУП различных классов. Там же (приме нительно к АСУП с дискретным характером производства) указывается, что «...классификация должна быть основана на сравнительно небольшом количестве грубых оценок АСУП. Она должна удовлетворять требованиям проектирования на базе унифицированных и плановых проектных решений». В качестве классификационных признаков авторы [6] рекомен дуют: А — характеристики предприятия (тип производства и размер предприятия, тыс. чел.); Б — характеристики автоматизированной части системы уп равления (охват автоматизацией функций управления с учетом уровня иерархии, объем программ специального математического обеспечения, тыс. команд; уровень автоматизации программирования, состав основных средств вычислительной техники); В — характеристики взаимосвязи автоматизированной части и объекта управления (способ связи с объектом, назначение основных алгоритмов управления, периодичность взаимодействия по выходу). Рассматривая более широкий класс автоматизированных систем управления (АСУ), можно предложить и иные подходы к классификации АСУ. По мере расширения области применения АСУ и совершенствования методов их создания меняются требования, области применения и методика классификации АСУ, значительные изменения происходят и в терминологии. Так, приведенное в действующем ГОСТе [22] определение АСУ как человеко- машинной системы, обеспечивающей сбор и обработку информации, необходимой для оптимизации управления в различных сферах человеческой деятельности, не полностью характеризует функционирующие и создаваемые системы. Многие действующие системы не ограничиваются сбором и обработкой информации, а, производя распознавание состояния объекта управления, выдают (и реализуют через соответствующие устройства) управляющие воздействия. Не случайно поэтому некоторые авторы предлагают и другие определения АСУ. Для возможности учета особенностей исследуемых объектов управления и предварительного определения укрупненных характеристик планируемой АСУ целесообразно использовать классификации систем, проводимые по следующим четырем основным признакам [35]: 1) степени автоматизации, 2) уровню управления, 3) интервалу управления, 4) функциональному назначению. Несмотря на большое разнообразие объектов, подверженных различным видам возмущающих воздействий (станки, технологические процессы, группы технологических агрегатов, коллективы людей, промышленные, культурные, медицинские или сельскохозяйственные предприятия и т. д.), можно указать на их некоторые общие свойства, результаты анализа которых являются исходными для принятия основных принципиальных решений при создании АСУ. В качестве исходной модели рассмотрим укрупненную схему технологии сбора, передачи, обработки информации и выбора управляющих воздействий на объект управления (схема 1). На вход любого объекта подаются ресурсы (материалы, полуфабрикаты, энергия и т. д.), на выходе фиксируется конечная продукция. На входе и выходе объекта производится сбор информации, которая поступает в центры хранения и предварительной обработки. Затем происходит истолкование информации с целью анализа состояния объекта, при этом учитываются директивные указания вышестоящих уровней. Информация конкретизируется в виде модели, отражающей конкретные цели и критерии функционирования объекта в рассматриваемом интервале времени. Когда состояние объекта определено и намечена траектория его движения, необходимо произвести расчеты вариантов плана действий с учетом нормативных данных. Полученные варианты проектов решения согласовываются с основными целями и критериями. После выполнения всех необходимых расчетов наступает этап выбора управляющих решений (воздействий). Поскольку управляющее воздействие реализуется применительно к объекту управления, меняет его состояние, то следует внести коррективы в модель системы. Для повышения эффективности вырабатываемых решений нужно учитывать влияние внешней среды и в первую очередь возмущающих воздействий. Информация об этих воздействия; поступает (штриховая линия) как в блок хранения исходной Схема 1. Укрупненная схема технологии сбора, передачи, хранения и обработки информации информации, так и оперативно используется при выборе управляющего воздействия (блок выбора управляющего воздействия). Приведенная схема является достаточно общей и в зависимости от конкретных функций, реализуемых объектом управления и управляющей системой, и методов их реализации может быть описана в соответствии с классификационными признаками. По степени автоматизации автоматизированные системы могут быть разделены на информационные, информационно-советующие и управляющие. Информационная система (схема 2). Всякий производственный процесс имеет управляемые переменные, на которые можно целенаправленно воздействовать, и неуправляемые, которые в каждой конкретной ситуации не поддаются изменению. На входе Схема 2. Информационная система и выходе объекта управления установлены измерительные элементы {ИЭ), с помощью которых собирается информация о входных характеристиках, результатах функционирования объекта и исследуемых процессов. Эта информация направляется на ЭВМ. Будучи переработанной по заранее заданным алгоритмам, ин формация в удобном для восприятия человеком виде поступает на устройство регистрации параметров процесса (УРПП). Оценивая полученную информацию, оператор формулирует, управляющие воздействия и через управляющие органы (УО) реализует эти воздействия, изменяя значение управляемых переменных. В некоторых случаях, когда не требуется вмешательства человека, технические средства системы производят автоматически регулировку параметров технологических процессов (или другие более сложные операции), не акцентируя на этом внимания оператора. Регистрируемые результаты работы автоматических устройств управления используются в дальнейшем обычно при статистическом анализе характера протекания технологических процессов. Таким образом, основное назначение информационной системы заключается в обеспечении оператора необходимой информацией, представленной в удобном для восприятия виде. Схема 3. Информационно-советующая система Информационно-советующая система (схема 3). Информация, собранная с помощью измерительных элементов о функционировании объекта управления и состоянии внешней среды, поступает на ЭВМ. Последняя, используя комплекс программ, обрабатывает информацию по заданным алгоритмам. Результаты обработки в удобном для восприятия оператором виде поступают на выводное устройство (печать, видеозапись и т. д.) в виде совета. Оператор использует эту информацию и с учетом дополнительных сведений, поступающих по другим (помимо АСУ) каналам, вырабатывает управляющие воздействия. Наличие обратной связи — фиксация в памяти ЭВМ принимаемых решений — придает системе свойства самообучающейся АСУ. Таким образом, информационносоветующая система наряду с выдачей информации и фиксацией необходимых характеристик объекта и процессов, т. е. выполнением функций информационной системы, подготавливает определенные предложения и рекомендации оператору, например режим и график работы в данной конкретной ситуации. При этом окончательное принятие решений остается за человеком (отсюда термин «информационно-советующая система»). Управляющая система. Данная система отличается от информационно-советующей тем, что вырабатываемые ЭВМ советы могут быть реализованы через управляющие органы (УО) без вмешательства человека. Оператор (схема 4) не включен непосредственно в контур управления, но может корректировать вырабатываемые ЭВМ советы. Примером управляющей системы могут служить некоторые типы АСУТП, если конечному числу состояний объекта управления соответствует конкретное число возможных управляющих воздействий, т. е. когда техническими средствами практически реализуется закон необходимого разнообразия. Классификация по уровню (иерархии) управления. Применительно к различным уровням управления разработаны или разрабатываются разные АСУ, начиная от управления отдельным технологическим процессом (АСУТП), комплексом технологических процессов, цехом, производством и кончая АСУО. (Системы более высокого ранга здесь не рассматриваются.) Четкая классификация по уровню управления обнажает связи между иерархиями системы, создает предпосылки для продуктивного исследования взаимного влияния параметров этих связей и определения места и роли локальных АСУ (с учетом горизонтальных связей) в общей системе автоматизированного управления. Такая классификация способствует определению внутреннего содержания подсистем каждого уровня, которое, естественно, меняется как по составу и объему решаемых задач, времени их решения, требованиям к КТС, так и по важности (ценности) решения для системы в целом. Данная классификация позволяет провести синтез различных элементов и выполняемых ими функций по организационному признаку, конкретизировать понятие «сложность» и «масштабность» систем, увязать уровни для согласования их функционирования, создать предпосылки для разработки интегрированных, в том числе организационно-технологических АСУ. Классификация по времени управления. Необходимость увязки функционирования отдельных звеньев любой (тем паче сложной) системы во времени очевидна, особенно для предприятий с дискретным характером производства. Содержание комплекса Схема 4. Информационно-управляющая система управляющих операций (от перспективного планирования до внутрисменного регулирования — диспетчеризации и далее к управлению быстропротекающими процессами) в значительной степени определяет допустимый интервал времени на подго- товку, принятие и реализацию решения. Увеличение скорости протекания производственных и технологических процессов при одновременном росте объемов информации об управляемых объектах и процессах предъявляет повышенные требования к производительности систем сбора, передачи и, главное, переработ ки информации. В свою очередь, скорость подготовки (получения) решения в значительной степени обусловливает требования к конфигурации вычислительной системы и всего КТС, к системе математического обеспечения, к структуре информационной базы и к другим существенным элементам АСУ. Рассмотрение на конкретных примерах (или фрагментах принятия решений на стадии технического задания) связей между получением некоторых желаемых услуг от АСУ и требований к создаваемой системе — в том числе к ее реальному быстродействию — позволит подойти к оценке возможностей современных АСУ, сопоставить желаемое и действительное. Классификация по функциональному признаку. Каждая система (подсистема) управления предназначена для выполнения вполне определенных функций. Система управления технологическим процессом обеспечивает реализацию заданных режимов переработки исходного сырья, материалов или полуфабрикатов в конечную (или промежуточную) продукцию. При этом в зависимости от поставленной цели может быть реализована одна или несколько заданных функций: стабилизация отдельных технологических параметров; регулирование (или программное изменение) технологического режима; однотактное логическое управление отдельными операциями или аппаратами (автоматические переключения, блокировки и т. п.) ; программное логическое управление агрегатами по «жесткому» циклу (числовое программное управление станком, управление манипуляторами); оптимальное управление процессом в целом (управление комплексноавтоматизированным участком станков с ЧПУ). Часто системы управления технологическими процессами выполняют информационные функции: обобщенная оценка и прогноз состояния оборудования и хода процесса (распознавание ситуаций, диагностика аварий, поиск «узкого места», выявление и прогноз развития тенденций в процессе и т. д.), передача данных в другие системы управления (что необходимо при работе АСУТП в рамках АСУОТ) и т. д. Организационно-экономическое управление, осуществляемое на уровнях цеха, предприятия, объединения, также реализуется по функциям. В справочном пособии [6] помимо общей схемы классификации приводится поэлементная, в том числе схема классификации функциональных задач управления АСУП. Используемые классификации АСУ, не являясь исчерпывающими, все же значительно облегчают решение многих задач проектирования конкретной системы [35]. Так, функциональный признак позволяет выделить целевую направленность анализа и проектирования, временной — увязать функционирование отдельных подсистем во времени, степень автоматизации — согласовать уровень подготовленности системы и целесообразность автоматизации конкретных функций управления с имеющимися техническими возможностями. Лекция 4 АСУ ТП(Автоматизированная система управления технологическим процессом) Автоматизированная система управления технологическим процессом (сокр. АСУТП) — комплекс технических и программных средств, предназначенный для автоматизации управления технологическим оборудованием на промышленных предприятиях. Может иметь связь с более глобальной автоматизированной системой управления предприятием (АСУП). Под АСУТП обычно понимается комплексное решение, обеспечивающее автоматизацию основных технологических операций технологического процесса на производстве в целом или каком-то его участке, выпускающем относительно завершенный продукт. Термин «автоматизированный» в отличие от термина «автоматический» подчеркивает необходимость участия человека в отдельных операциях, как в целях сохранения контроля над процессом, так и в связи со сложностью или нецелесообразностью автоматизации отдельных операций. Составными частями АСУТП могут быть отдельные системы автоматического управления (САУ) и автоматизированные устройства, связанные в единый комплекс. Как правило АСУТП имеет единую систему операторского управления технологическим процессом в виде одного или нескольких пультов управления, средства обработки и архивирования информации о ходе процесса, типовые элементы автоматики: датчики, устройства управления, исполнительные устройства. Для информационной связи всех подсистем используются промышленные сети. В английской литературе для обозначения АСУ ТП обычно используются термины Process Control Systems или реже Automatic Control Systems (последнее определение, на мой взгляд, несколько абстрактно, так как не указывает на конкретное предназначение системы управления). Здесь важно сделать акцент на слове “автоматизированная”. Под этим подразумевается, что система управления отнюдь не полностью автономна (самостоятельна), и требуется участие человека (оператора) для реализации определенных задач. Выражение “пустил и забыл” для таких систем не подходит. Напротив, системы автоматического управления (САУ) предназначены для работы без какого-либо контроля со стороны человека и полностью автономны. Очень важно понимать эту принципиальную разницу между АСУ и САУ. Классификация АСУ ТП В зарубежной литературе можно встретить довольно интересную классификацию АСУ ТП, в соответствие с которой все АСУ ТП делятся на три глобальных класса: • SCADA (Supervisory Control and Data Acquisition). На русский язык этот термин можно перевести как “система телемеханики”, “система телеметрии” или “ система диспетчерского управления”. На мой взгляд, последнее определение точнее всего отражает сущность и предназначение системы - контроль и мониторинг объектов с участием диспетчера. Тут необходимо некоторое пояснение. Термин SCADA часто используется в более узком смысле: многие так называют программный пакет визуализации технологического процесса. Однако в данном разделе под словом SCADA мы будем понимать целый класс систем управления. • PLC (Programmable Logic Controller). На русский язык переводится как “программируемый логический контроллер” (или сокращенно ПЛК). Тут, как и в предыдущем случае, есть двусмысленность. Под термином ПЛК часто подразумевается аппаратный модуль для реализации алгоритмов автоматизированного управления. Тем не менее, термин ПЛК имеет и более общее значение и часто используется для обозначения целого класса систем. • DCS (Distributed Control System). По-русски распределенная система управления (РСУ). Тут никакой путаницы нет, все однозначно. Справедливости ради надо отметить, что если в начале 90-х такая классификация не вызывала споров, то сейчас многие эксперты считают ее весьма условной. Это связано с тем, что в последние годы внедряются гибридные системы, которые по ряду характерных признаков можно отнести как к одному классу, так и к другому. АСУ ТП и диспетчерское управление Непрерывную во времени картину развития АСУ ТП можно разделить на три этапа, обусловленные появлением качественно новых научных идей и технических средств. В ходе истории меняется характер объектов и методов управления, средств автоматизации и других компонентов, составляющих содержание современной системы управления. Первый этап отражает внедрение систем автоматического регулирования (САР). Объектами управления на этом этапе являются отдельные параметры, установки, агрегаты. Решение задач стабилизации, программного управления, слежения переходит от человека к САР. У человека появляются функции расчета задания и параметров настройки регуляторов. Второй этап - автоматизация технологических процессов. Объектом управления становится рассредоточенная в пространстве система. С помощью систем автоматического управления (САУ) реализуются все более сложные законы управления, решаются задачи оптимального и адаптивного управления, проводится идентификация объекта и состояния системы. Характерной особенностью этого этапа является внедрение систем телемеханики в управление технологическими процессами. Человек все больше отдаляется от объекта управления, между объектом и диспетчером выстраивается целый ряд измерительных систем, исполнительных механизмов, средств телемеханики, мнемосхем и других средств отображения информации (СОИ). Третий этап - автоматизация систем управления технологическими процессами характеризуется внедрением в управление технологическими процессами вычислительной техники. Вначале - применение микропроцессоров, использование на отдельных фазах управления вычислительных систем; затем - активное развитие человеко-машинных систем управления, инженерной психологии, методов и моделей исследования операций и, наконец, - диспетчерское управление на основе автоматических информационных систем сбора данных и современных вычислительных комплексов. От этапа к этапу меняются и функции человека (оператора/диспетчера), призванного обеспечить регламентное функционирование технологического процесса. Расширяется круг задач, решаемых на уровне управления. Ограниченный прямой необходимостью управления технологическим процессом набор задач пополняется качественно новыми задачами, ранее имеющими вспомогательный характер или относящимися к другому уровню управления. Диспетчер в многоуровневой автоматизированной системе управления технологическими процессами получает информацию с монитора ЭВМ или с электронной системы отображения информации и воздействует на объекты, находящиеся от него на значительном расстоянии, с помощью телекоммуникационных систем, контроллеров, интеллектуальных исполнительных механизмов. Основой, необходимым условием эффективной реализации диспетчерского управления, имеющего ярко выраженный динамический характер, становится работа с информацией, т.е. процесс сбора, передачи, обработки, отображения, представления информации. От диспетчера ухе требуется не только профессиональное знание технологического процесса, основ управления, но и опыт работы в информационных системах, умение принимать решение (в диалоге с ЭВМ} в нештатных и аварийных ситуациях и многое другое. Диспетчер становится главным действующим лицом в управлении технологическим процессом. Говоря о диспетчерском управлении, нельзя не затронуть проблему технологического риска. Технологические процессы в энергетике, нефтегазовой и ряде других отраслей промышленности являются потенциально опасными и при возникновении аварий приводят к человеческим жертвам, а также к значительному материальному и экологическому ущербу. Статистика говорит, что за тридцать лет (с начала 60-х до конца 80-х годов ХХ века} число учтенных аварий удваивалось примерно каждые десять лет. B результате анализа большинства аварий и происшествий на всех видах транспорта, в промышленности и энергетике были получены интересные данные. B 60-х годах ошибка человека была первоначальной причиной аварий лишь в 20% случаев, тогда как к концу 80-х доля «человеческого фактора» стала приближаться к 80%. Одна из причин этой тенденции - старый, традиционный подход к построению сложных систем управления, т. е. ориентация на применение новейших технических и технологических достижений и недооценка необходимости построения эффективного человекомашинного интерфейса, ориентированного на человека (диспетчера}. Таким образом, требование повышения надежности систем диспетчерского управления является одной из предпосылок появления нового подхода при разработке таких систем. Основа современного подхода - ориентация на оператора/диспетчера и его задачи. Концепция SCADA (Supervisory Control And Data Acquisition - диспетчерское управление и сбор данных) предопределена всем ходом развития систем управления и результатами научно-технического прогресса. Применение SCADA-технологий позволяет достичь высокого уровня автоматизации B решении задач разработки систем управления, сбора, обработки, передачи, хранения и отображения информации. Дружественность человеко-машинного интерфейса (HMI/MMI - Humain/Маn Machine Interface), предоставляемого SCADA-системами, полнота и наглядность представляемой на экране информации, доступность «рычагов» управления, удобство пользования подсказками и справочной системой и т. д. повышают эффективность взаимодействия диспетчера с системой и сводят к минимуму его критические ошибки при управлении. Следует отметить, что концепция SCADA, основу которой составляет автоматизированная разработка и управление в реальном времени, позволяет решить еще ряд задач, долгое время считавшихся неразрешимыми: сокращение сроков разработки проектов по автоматизации и прямых финансовых затрат на их разработку. B настоящее время SCADA является основным и наиболее перспективным методом автоматизированного управления сложными динамическими системами (процессами). Управление технологическими процессами на основе систем SCADA стало осуществляться в передовых западных странах в 80-е годы. Область их применения охватывает сложные объекты электро- и водоснабжения, химические, нефтехимические и нефтеперерабатывающие производства, железнодорожный транспорт, транспорт нефти и газа и др. В России диспетчерское управление технологическими процессами опиралось, главным образом, на опыт оперативно-диспетчерского персонала. Переход к управлению на основе SCADA-систем стал осуществляться позднее. K трудностям освоения в России новой информационной технологии — SCADA-систем — относятся как отсутствие эксплуатационного опыта, так и недостаток информации о различных SCADA-системах. B мире насчитываются не один десяток компаний, активно занимающихся разработкой и внедрением SCADA-систем. Каждая SCADA-система — это ноу-хау компании, и поэтому информация о той или иной системе не столь обширна. Большое значение при внедрении современных систем диспетчерского управления имеет решение следующих задач: - выбор SCADA-системы (исходя из требований и особенностей технологического процесса); - кадровое сопровождение. Выбор SCADA-системы представляет собой достаточно трудную задачу, аналогичную принятию решений в условиях многокритериальности, усложненную невозможностью количественной оценки ряда критериев из-за недостатка информации. Подготовка специалистов по разработке и эксплуатации систем управления на базе программного обеспечения SCADA осуществляется на специализированных курсах различных фирм, курсах повышения квалификации. B настоящее время в учебные планы ряда технических университетов начали вводиться дисциплины, связанные с изучением SCADA-систем. Однако специальная литература по SCADA-системам отсутствует, имеются лишь отдельные статьи и рекламные проспекты. Лекция 5 SCADA-системы Современная АСУТП (автоматизированная система управления технологическим процессом) представляет собой многоуровневую человеко-машинную систему управления. Создание АСУ сложными технологическими процессами осуществляется с использованием автоматических информационных систем сбора данных и вычислительных комплексов, которые постоянно совершенствуются по мере эволюции технических средств и программного обеспечения. АСУ ТП и диспетчерское управление Непрерывную во времени картину развития АСУТП можно разделить на три этапа, обусловленные появлением качественно новых научных идей и технических средств. В ходе истории меняется характер объектов и методов управления, средств автоматизации и других компонентов, составляющих содержание современной системы управления.    Первый этап отражает внедрение систем автоматического регулирования (САР). Объектами управления на этом этапе являются отдельные параметры, установки, агрегаты; решение задач стабилизации, программного управления, слежения переходит от человека к САР. У человека появляются функции расчета задания и параметры настройки регуляторов. Второй этап - автоматизация технологических процессов. Объектом управления становится рассредоточенная в пространстве система; с помощью систем автоматического управления (САУ) реализуются все более сложные законы управления, решаются задачи оптимального и адаптивного управления, проводится идентификация объекта и состояний системы. Характерной особенностью этого этапа является внедрение систем телемеханики в управление технологическими процессами. Человек все больше отдаляется от объекта управления, между объектом и диспетчером выстраивается целый ряд измерительных систем, исполнительных механизмов, средств телемеханики, мнемосхем и других средств отображения информации (СОИ). Третий этап - автоматизированные системы управления технологическими процессами - характеризуется внедрением в управление технологическими процессами вычислительной техники. Вначале - применение микропроцессоров, использование на отдельных фазах управления вычислительных систем; затем активное развитие человеко-машинных систем управления, инженерной психологии, методов и моделей исследования операций и, наконец, диспетчерское управление на основе использования автоматических информационных систем сбора данных и современных вычислительных комплексов. От этапа к этапу менялись и функции человека (оператора/диспетчера), призванного обеспечить регламентное функционирование технологического процесса. Расширяется круг задач, решаемых на уровне управления; ограниченный прямой необходимостью управления технологическим процессом набор задач пополняется качественно новыми задачами, ранее имеющими вспомогательный характер или относящиеся к другому уровню управления. Диспетчер в многоуровневой автоматизированной системе управления технологическими процессами получает информацию с монитора ЭВМ или с электронной системы отображения информации и воздействует на объекты, находящиеся от него на значительном расстоянии с помощью телекоммуникационных систем, контроллеров, интеллектуальных исполнительных механизмов. Основой, необходимым условием эффективной реализации диспетчерского управления, имеющего ярко выраженный динамический характер, становится работа с информацией, т. е. процессы сбора, передачи, обработки, отображения, представления информации. От диспетчера уже требуется не только профессиональное знание технологического процесса, основ управления им, но и опыт работы в информационных системах, умение принимать решение (в диалоге с ЭВМ) в нештатных и аварийных ситуациях и многое другое. Диспетчер становится главным действующим лицом в управлении технологическим процессом. Говоря о диспетчерском управлении, нельзя не затронуть проблему технологического риска. Технологические процессы в энергетике, нефтегазовой и ряде других отраслей промышленности являются потенциально опасными и при возникновении аварий приводят к человеческим жертвам, а также к значительному материальному и экологическому ущербу. Статистика говорит, что за тридцать лет число учтенных аварий удваивается примерно каждые десять лет. В основе любой аварии за исключением стихийных бедствий лежит ошибка человека. В результате анализа большинства аварий и происшествий на всех видах транспорта, в промышленности и энергетике были получены интересные данные. В 60 - х годах ошибка человека была первоначальной причиной аварий лишь в 20% случаев, тогда как к концу 80-х доля "человеческого фактора" стала приближаться к 80 %. Одна из причин этой тенденции - старый традиционный подход к построению сложных систем управления, т. е. ориентация на применение новейших технических и технологических достижений и недооценка необходимости построения эффективного человеко - машинного интерфейса, ориентированного на человека (диспетчера). Таким образом, требование повышения надежности систем диспетчерского управления является одной из предпосылок появления нового подхода при разработке таких систем: ориентация на оператора/диспетчера и его задачи. Концепция SCАDA (Supervisory Control And Data Acquisition - диспетчерское управление и сбор данных) предопределена всем ходом развития систем управления и результатами научно-технического прогресса. Применение SCADA-технологий позволяет достичь высокого уровня автоматизации в решении задач разработки систем управления, сбора, обработки, передачи, хранения и отображения информации. Дружественность человеко-машинного интерфейса (HMI/MMI), предоставляемого SCADA - системами, полнота и наглядность представляемой на экране информации, доступность "рычагов" управления, удобство пользования подсказками и справочной системой и т. д. - повышает эффективность взаимодействия диспетчера с системой и сводит к нулю его критические ошибки при управлении. Следует отметить, что концепция SCADA, основу которой составляет автоматизированная разработка систем управления, позволяет решить еще ряд задач, долгое время считавшихся неразрешимыми: сократить сроки разработки проектов по автоматизации и прямые финансовые затраты на их разработку. В настоящее время SCADA является основным и наиболее перспективным методом автоматизированного управления сложными динамическими системами (процессами). Управление технологическими процессами на основе систем SCADA стало осуществляться в передовых западных странах в 80-е годы. Область применения охватывает сложные объекты электро- и водоснабжения, химические, нефтехимические и нефтеперерабатывающие производства, железнодорожный транспорт, транспорт нефти и газа и др. В России диспетчерское управление технологическими процессами опиралось, главным образом, на опыт оперативно-диспетчерского персонала. Поэтому переход к управлению на основе SCADA-систем стал осуществляться несколько позднее. К трудностям освоения в России новой информационной технологии, какой являются SCADA-системы, относится как отсутствие эксплуатационного опыта, так и недостаток информации о различных SCADA-системах. В мире насчитывается не один десяток компаний, активно занимающихся разработкой и внедрением SCADA-систем. Каждая SCADA-система - это "know-how" компании и поэтому данные о той или иной системе не столь обширны. Большое значение при внедрении современных систем диспетчерского управления имеет решение следующих задач:   выбора SCADA-системы (исходя из требований и особенностей технологического процесса); кадрового сопровождения. Выбор SCADA-системы представляет собой достаточно трудную задачу, аналогичную принятию решений в условиях многокритериальности, усложненную невозможностью количественной оценки ряда критериев из-за недостатка информации. Подготовка специалистов по разработке и эксплуатации систем управления на базе программного обеспечения SCADA осуществляется на специализированных курсах различных фирм, курсах повышения квалификации. В настоящее время в учебные планы ряда технических университетов начали вводиться дисциплины, связанные с изучением SCADA-систем. Однако специальная литература по SCADA-системам отсутствует; имеются лишь отдельные статьи и рекламные проспекты. Компоненты систем контроля и управления и их назначение Многие проекты автоматизированных систем контроля и управления (СКУ) для большого спектра областей применения позволяют выделить обобщенную схему их реализации, представленную на рис.1. Рис.1. Обобщенная схема системы контроля и управления. Как правило, это двухуровневые системы, так как именно на этих уровнях реализуется непосредственное управление технологическими процессами. Специфика каждой конкретной системы управления определяется используемой на каждом уровне программно - аппаратной платформой.  Нижний уровень - уровень объекта (контроллерный) - включает различные датчики для сбора информации о ходе технологического процесса, электроприводы и исполнительные механизмы для реализации регулирующих и управляющих воздействий. Датчики поставляют информацию локальным программируемым логическим контроллерам (PLC - Programming Logical Controoller), которые могут выполнять следующие функции: o сбор и обработка информации о параметрах технологического процесса; o управление электроприводами и другими исполнительными механизмами; o решение задач автоматического логического управления и др. Так как информация в контроллерах предварительно обрабатывается и частично используется на месте, существенно снижаются требования к пропускной способности каналов связи. В качестве локальных PLC в системах контроля и управления различными технологическими процессами в настоящее время применяются контроллеры как отечественных производителей, так и зарубежных. На рынке представлены многие десятки и даже сотни типов контроллеров, способных обрабатывать от нескольких переменных до нескольких сот переменных. К аппаратно-программным средствам контроллерного уровня управления предъявляются жесткие требования по надежности, времени реакции на исполнительные устройства, датчики и т.д. Программируемые логические контроллеры должны гарантированно откликаться на внешние события, поступающие от объекта, за время, определенное для каждого события. Для критичных с этой точки зрения объектов рекомендуется использовать контроллеры с операционными системами реального времени (ОСРВ). Контроллеры под управлением ОСРВ функционируют в режиме жесткого реального времени. Разработка, отладка и исполнение про-грамм управления локальными контроллерами осуществляется с помощью специализированного программного обеспечения, широко представленного на рынке. К этому классу инструментального ПО относятся пакеты типа ISaGRAF (CJ International France), InConrol (Wonderware, USA), Paradym 31 (Intellution, USA), имеющие открытую архитектуру.   Информация с локальных контроллеров может направляться в сеть диспетчерского пункта непосредственно, а также через контроллеры верхнего уровня (см. рис.). В зависимости от поставленной задачи контроллеры верхнего уровня (концентраторы, интеллектуальные или коммуникационные контроллеры) реализуют различные функции. Некоторые из них перечислены ниже: o сбор данных с локальных контроллеров; o обработка данных, включая масштабирование; o поддержание единого времени в системе; o синхронизация работы подсистем; o организация архивов по выбранным параметрам; o обмен информацией между локальными контроллерами и верхним уровнем; o работа в автономном режиме при нарушениях связи с верхним уровнем; o резервирование каналов передачи данных и др. Верхний уровень - диспетчерский пункт (ДП) - включает, прежде всего, одну или несколько станций управления, представляющих собой автоматизированное рабочее место (АРМ) диспетчера/оператора. Здесь же может быть размещен сервер базы данных, рабочие места (компьютеры) для специалистов и т. д. Часто в качестве рабочих станций используются ПЭВМ типа IBM PC различных конфигураций. Станции управления предназначены для отображения хода технологического процесса и оперативного управления. Эти задачи и призваны решать SCADA системы. SCADА - это специализированное программное обеспечение, ориентированное на обеспечение интерфейса между диспетчером и системой управления, а также коммуникацию с внешним миром. Спектр функциональных возможностей определен самой ролью SCADA в системах управления и реализован практически во всех пакетах: o o o o o автоматизированная разработка, дающая возможность создания ПО системы автоматизации без реального программирования; средства исполнения прикладных программ; сбор первичной информации от устройств нижнего уровня; обработка первичной информации; регистрация алармов и исторических данных; o o o хранение информации с возможностью ее пост-обработки (как правило, реализуется через интерфейсы к наиболее популярным базам данных); визуализация информации в виде мнемосхем, графиков и т.п.; возможность работы прикладной системы с наборами параметров, рассматриваемых как "единое целое" ("recipe" или "установки"). Рассматривая обобщенную структуру систем управления, следует ввести и еще одно понятие - Micro-SCADA. Micro-SCADA - это системы, реализующие стандартные (базовые) функции, присущие SCADA - системам верхнего уровня, но ориентированные на решение задач автоматизации в определенной отрасли (узкоспециализированные). В противоположность им SCADA - системы верхнего уровня являются универсальными.    Все компоненты системы управления объединены между собой каналами связи. Обеспечение взаимодействия SCADA - систем с локальными контроллерами, контроллерами верхнего уровня, офисными и промышленными сетями возложено на так называемое коммуникационное ПО. Это достаточно широкий класс программного обеспечения, выбор которого для конкретной системы управления определяется многими факторами, в том числе и типом применяемых контроллеров, и используемой SCADA - системой. Более подробная информация о коммуникационном ПО приведена в главе 2. Большой объем информации, непрерывно поступающий с устройств ввода/вывода систем управления, предопределяет наличие в таких системах баз данных (БД). Основная задача баз данных - своевременно обеспечить пользователя всех уровней управления требуемой информацией. Но если на верхних уровнях АСУ эта задача решена с помощью традиционных БД, то этого не скажешь об уровне АСУ ТП. До недавнего времени регистрация информации в реальном времени решалась на базе ПО интеллектуальных контроллеров и SCADA - систем. В последнее время появились новые возможности по обеспечению высокоскоростного хранения информации в БД. Более подробная информация по базам данных реального времени приведена в главе 6. Бурное развитие Интернет не могло не привлечь внимание производителей программного продукта SCADA. Возможно ли применение Интернет - технологий в системах управления технологическими процессами? Если да, то какие решения предлагаются в настоящее время компаниями - разработчиками? Обсуждению этих вопросов посвящена глава 7. Разработка прикладного программного обеспечения СКУ: выбор пути и инструментария Приступая к разработке специализированного прикладного программного обеспечения (ППО) для создания системы контроля и управления, системный интегратор или конечный пользователь обычно выбирает один из следующих путей:   Программирование с использованием "традиционных" средств (традиционные языки программирования, стандартные средства отладки и пр.) Использование существующих, готовых - COTS (Commercial Of The Shelf) инструментальных проблемно-ориентированных средств. Для большинства выбор уже очевиден. Процесс разработки ППО важно упростить, сократить временные и прямые финансовые затраты на разработку ППО, минимизировать затраты труда высококлассных программистов, по возможности привлекая к разработке специалистов-технологов в области автоматизируемых процессов. При такой постановке задачи второй путь может оказаться более предпочтительным. Для сложных распределенных систем процесс разработки собственного ППО с использованием "традиционных" средств может стать недопустимо длительным, а затраты на его разработку неоправданно высокими. Вариант с непосредственным программированием относительно привлекателен лишь для простых систем или небольших фрагментов большой системы, для которых нет стандартных решений (не написан, например, подходящий драйвер) или они не устраивают по тем или иным причинам в принципе. Итак, выбор пути сделан! Это очень важно, но тогда следует сделать и второй шаг "определиться" с инструментальными средствами разработки ППО. Программные продукты класса SCADA широко представлены на мировом рынке. Это несколько десятков SCADA - систем, многие из которых нашли свое применение и в России. Наиболее популярные из них приведены ниже:           InTouch (Wonderware) - США; Citect (CI Technology) - Австралия; FIX (Intellution ) - США; Genesis (Iconics Co) - США; Factory Link (United States Data Co) - США; RealFlex (BJ Software Systems) - США; Sitex (Jade Software) - Великобритания; TraceMode (AdAstrA) - Россия; Cimplicity (GE Fanuc) - США; САРГОН (НВТ - Автоматика) - Россия. При таком многообразии SCADA - продуктов на российском рынке естественно возникает вопрос о выборе. Выбор SCADA-системы представляет собой достаточно трудную задачу, аналогичную поиску оптимального решения в условиях многокритериальности. Ниже приводится примерный перечень критериев оценки SCADA - систем, которые в первую очередь должны интересовать пользователя. Этот перечень не является авторским и давно уже обсуждается в специальной периодической прессе. В нем можно выделить три большие группы показателей:    технические характеристики; стоимостные характеристики; эксплуатационные характеристики. Технические характеристики Программно-аппаратные платформы для SCADA-систем. Анализ перечня таких платформ необходим, поскольку от него зависит ответ на вопрос, возможна ли реализация той или иной SCADA-системы на имеющихся вычислительных средствах, а также оценка стоимости эксплуатации системы (будучи разработанной в одной операционной среде, прикладная программа может быть выполнена в любой другой, которую поддерживает выбранный SCADA-пакет). В различных SCADA- системах этот вопрос решен по разному. Так, FactoryLink имеет весьма широкий список поддерживаемых программно-аппаратных платформ: Операционная система DOS/MS Windows OS/2 SCO UNIX VMS AIX HP-UX MS Windows/NT Компьютерная платформа IBM PC IBM PC IBM PC VAX RS6000 HP 9000 Системы с реализованным Windows/NT, в основном на РСплатформе. В то же время в таких SCADA-системах, как RealFlex и Sitex основу программной платформы принципиально составляет единственная операционная система реального времени QNX. Подавляющее большинство SCADA-систем реализовано на MS Windows платформах. Именно такие системы предлагают наиболее полные и легко наращиваемые MMI средства. Учитывая позиции Microsoft на рынке операционных систем (ОС), следует отметить, что даже разработчики многоплатформных SCADA-систем, такие как United States DATA Co (разработчик FactoryLink), приоритетным считают дальнейшее развитие своих SCADA-систем на платформе Windows NT. Некоторые фирмы, до сих пор поддерживавшие SCADA-системы на базе операционных систем реального времени (ОСРВ), начали менять ориентацию, выбирая системы на платформе Windows NT. Все более очевидным становится применение ОСРВ, в основном, во встраиваемых системах, где они действительно хороши. Таким образом, основным полем, где сегодня разворачиваются главные события глобального рынка SCADA--систем, стала MS Windows NT/2000 на фоне всё ускоряющегося сворачивания активности в области MS DOS, MS Windows 3.xx/95. Имеющиеся средства сетевой поддержки. Одной из основных черт современного мира систем автоматизации является их высокая степень интеграции. В любой из них могут быть задействованы объекты управления, исполнительные механизмы, аппаратура, регистрирующая и обрабатывающая информацию, рабочие места операторов, серверы баз данных и т.д. Очевидно, что для эффективного функционирования в этой разнородной среде SCADA-система должна обеспечивать высокий уровень сетевого сервиса. Желательно, чтобы она поддерживала работу в стандартных сетевых средах (ARCNET, ETHERNET и т.д.) с использованием стандартных протоколов (NETBIOS, TCP/IP и др.), а также обеспечивала поддержку наиболее популярных сетевых стандартов из класса промышленных интерфейсов (PROFIBUS, CANBUS, LON, MODBUS и т.д.) Этим требованиям в той или иной степени удовлетворяют практически все рассматриваемые SCADA-системы, с тем только различием, что набор поддерживаемых сетевых интерфейсов, конечно же, разный. Встроенные командные языки. Большинство SCADA-систем имеют встроенные языки высокого уровня, VBasicподобные языки, позволяющие генерировать адекватную реакцию на события, связанные с изменением значения переменной, с выполнением некоторого логического условия, с нажатием комбинации клавиш, а также с выполнением некоторого фрагмента с заданной частотой относительно всего приложения или отдельного окна. Поддерживаемые базы данных. Одной из основных задач систем диспетчерского контроля и управления является обработка информации: сбор, оперативный анализ, хранение, сжатие, пересылка и т. д. Таким образом, в рамках создаваемой системы должна функционировать база данных. Практически все SCADA-системы, в частности, Genesis, InTouch, Citect, используют ANSI SQL синтаксис, который является независимым от типа базы данных. Таким образом, приложения виртуально изолированы, что позволяет менять базу данных без серьезного изменения самой прикладной задачи, создавать независимые программы для анализа информации, использовать уже наработанное программное обеспечение, ориентированное на обработку данных. Графические возможности. Для специалиста-разработчика системы автоматизации, также как и для специалиста "технолога", чье рабочее место создается, очень важен графический пользовательский интерфейс. Функционально графические интерфейсы SCADA-систем весьма похожи. В каждой из них существует графический объектно-ориентированный редактор с определенным набором анимационных функций. Используемая векторная графика дает возможность осуществлять широкий набор операций над выбранным объектом, а также быстро обновлять изображение на экране, используя средства анимации. Крайне важен также вопрос о поддержке в рассматриваемых системах стандартных функций GUI (Graphic Users Interface). Поскольку большинство рассматриваемых SCADA-систем работают под управлением Windows, это и определяет тип используемого GUI. Открытость систем Система является открытой, если для нее определены и описаны используемые форматы данных и процедурный интерфейс, что позволяет подключить к ней "внешние", независимо разработанные компоненты. Разработка собственных программных модулей. Перед фирмами-разработчиками систем автоматизации часто встает вопрос о создании собственных (не предусмотренных в рамках систем SCADA) программных модулей и включение их в создаваемую систему автоматизации. Поэтому вопрос об открытости системы является важной характеристикой SCADA-систем. Фактически открытость системы означает доступность спецификаций системных (в смысле SCADA) вызовов, реализующих тот или иной системный сервис. Это может быть и доступ к графическим функциям, функциям работы с базами данных и т.д. Драйверы ввода-вывода. Современные SCADA-системы не ограничивают выбора аппаратуры нижнего уровня, так как предоставляют большой набор драйверов или серверов ввода-вывода и имеют хорошо развитые средства создания собственных программных модулей или драйверов новых устройств нижнего уровня. Сами драйверы разрабатываются с использованием стандартных языков программирования. Вопрос, однако, в том, достаточно ли только спецификаций доступа к ядру системы, поставляемых фирмой-разработчиком в штатном комплекте (система Trace Mode), или для создания драйверов необходимы специальные пакеты (системы FactoryLink, InTouch), или же, вообще, разработку драйвера нужно заказывать у фирмы-разработчика. Разработки третьих фирм. Многие компании занимаются разработкой драйверов, ActiveX-объектов и другого программного обеспечения для SCADA-систем. Этот факт очень важно оценивать при выборе SCADA-пакета, поскольку это расширяет область применения системы непрофессиональными программистами (нет необходимости разрабатывать программы с использованием языков С или Basic). Стоимостные характеристики При оценке стоимости SCADA-систем нужно учитывать следующие факторы:     стоимость программно-аппаратной платформы; стоимость системы; стоимость освоения системы; стоимость сопровождения. Эксплуатационные характеристики Показатели этой группы критериев наиболее субъективны. Это тот самый случай, когда лучше один раз увидеть, чем семь раз услышать. К этой группе можно отнести:    удобство интерфейса среды разработки - "Windows - подобный интерфейс", полнота инструментария и функций системы; качество документации - ее полнота, уровень русификации; поддержка со стороны создателей - количество инсталляций, дилерская сеть, обучение, условия обновления версий и т. д. Если предположить, что пользователь справился и с этой задачей - остановил свой выбор на конкретной SCADA - системе, то далее начинается разработка системы контроля и управления, которая включает следующие этапы:     Разработка архитектуры системы автоматизации в целом. На этом этапе определяется функциональное назначение каждого узла системы автоматизации. Решение вопросов, связанных с возможной поддержкой распределенной архитектуры, необходимостью введения узлов с "горячим резервированием" и т.п. Создание прикладной системы управления для каждого узла. На этом этапе специалист в области автоматизируемых процессов наполняет узлы архитектуры алгоритмами, совокупность которых позволяет решать задачи автоматизации. Приведение в соответствие параметров прикладной системы с информацией, которой обмениваются устройства нижнего уровня (например, программируемые  логические контроллеры - ПЛК) с внешним миром (датчики технологических параметров, исполнительные устройства и др.) Отладка созданной прикладной программы в режиме эмуляции. В последующих главах на примере двух известных и хорошо зарекомендовавших себя SCADAсистем (InTouch и Citect) рассмотрены основные компоненты, функции и возможности систем диспетчерского управления и сбора данных. Графический интерфейс Средства визуализации - одно из базовых свойств SCADA - систем. В каждой из них существует графический объектно - ориентированный редактор с определенным набором анимационных функций. Используемая векторная графика дает возможность осуществлять широкий круг операций над выбранным объектом. Объекты могут быть простыми (линии, прямоугольники, текстовые объекты и т. д.) и сложные. Возможности агрегирования сложных объектов в разных SCADA - системах различны. Все SCADA системы включают библиотеки стандартных графических символов, библиотеки сложных графических объектов, обладают целым рядом других стандартных возможностей. Но, тем не менее, каждая SCADA - система по-своему уникальна и, несмотря на поддержание стандартных функций, обладает присущими только ей особенностями. При рассмотрении графических возможностей SCADA - систем InTouch и Citect предполагается обратить внимание не только на возможности инструментариев по созданию графических объектов, но и на другие предоставляемые пользователю услуги, облегчающие и ускоряющие процесс разработки приложений (проектов). Лекция 6 1. Введение в базы данных В разделе рассматриваются базы данных и информационные системы. Описываются основные понятия баз данных и систем управления базами данных. Дается характеристика вариантов организации информационной системы по архитектуре клиентсервер. Приводится классификация СУБД, и описываются основные их функции. Рассматриваются варианты создания приложений и организации взаимодействия пользователей с информационными системами. 1.1. Базы данных и информационные системы В основе решения многих задач лежит обработка информации. Для облегчения обработки информации создаются информационные системы (ИС). Автоматизированными называют ИС, в которых применяют технические средства, в частности ЭВМ. Большинство существующих ИС являются автоматизированными, поэтому для краткости просто будем называть их ИС. В широком понимании под определение ИС подпадает любая система обработки информации. По области применения ИС можно разделить на системы, используемые в производстве, образовании, здравоохранении, науке, военном деле, социальной сфере, торговле и других отраслях. По целевой функции ИС можно условно разделить на следующие основные категории: управляющие, информационно-справочные, поддержки принятия решений. Заметим, что иногда используется более узкая трактовка понятия ИС как совокупности аппаратно-программных средств, задействованных для решения некоторой, прикладной задачи. В организации, например, могут существовать информационные системы, на которых соответственно возложены следующие задачи: учет кадров и материально-технических средств, расчет с поставщиками и заказчиками, бухгалтерский учет и т. п. Банк данных является разновидностью ИС, в которой реализованы функции централизованного хранения и накопления обрабатываемой информации, организованной в одну или несколько баз данных. Банк данных (БнД) в общем случае состоит из следующих компонентов: базы (нескольких баз) данных, системы управления базами данных, словаря данных, администратора, вычислительной системы и обслуживающего персонала. Вкратце рассмотрим названные компоненты и некоторые связанные с ними важные понятия. База данных (БД) представляет собой совокупность специальным образом организованных данных, хранимых в памяти вычислительной системы и отображающих состояние объектов и их взаимосвязей в рассматриваемой предметной области. Логическую структуру хранимых в базе данных называют моделью представления данных. К основным моделям представления данных (моделям данных) относятся следующие: иерархическая, сетевая, реляционная, постреляционная, многомерная и объектно-ориентированная. Система управления базами данных (СУБД) - это комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями. Обычно СУБД различают по используемой модели данных. Так, СУБД, основанные на использовании реляционной модели данных, называют реляционными СУБД. Одними из первых СУБД являются следующие системы: IMS (IBM, 1968 г.), IDMS (Cullinet, 1971 г.), ADABAS (Software AG, 1969 г.) и ИНЭС (ВНИИСИ АН СССР, 1976 г.). Количество современных систем управления базами данных исчисляется тысячами. Приложение представляет собой программу или комплекс программ, обеспечивающих автоматизацию обработки информации для прикладной задачи. Нами рассматриваются приложения, использующие БД. Приложения могут создаваться в среде или вне среды СУБД - с помощью системы программирования, использующей средства доступа к БД, к примеру, Delphi или C++ Builder. Приложения, разработанные в среде СУБД, часто называют приложениями СУБД, а приложения, разработанные вне СУБД, внешними приложениями. Для работы с базой данных зачастую достаточно средств СУБД и не нужно использовать приложения, создание которых требует программирования. Приложения разрабатывают главным образом в случаях, когда требуется обеспечить удобство работы с БД неквалифицированным пользователям или интерфейс СУБД не устраивает пользователей. Словарь данных (СД) представляет собой подсистему БнД, предназначенную для централизованного хранения информации о структурах данных, взаимосвязях файлов БД друг с другом, типах данных и форматах их представления, принадлежности данных пользователям, кодах защиты и разграничения доступа и т.п. Функционально СД присутствует во всех БнД, но не всегда выполняющий эти функции компонент имеет именно такое название. Чаще всего функции СД выполняются СУБД и вызываются из основного меню системы или реализуются с помощью ее утилит. Администратор базы данных (АБД) есть лицо или группа лиц, отвечающих за выработку требований к БД, ее проектирование, создание, эффективное использование и сопровождение. В процессе эксплуатации АБД обычно следит за функционированием информационной системы, обеспечивает защиту от несанкционированного доступа, контролирует избыточность, непротиворечивость, сохранность и достоверность хранимой в БД информации. Для однопользовательских информационных систем функции АБД обычно возлагаются на лиц, непосредственно работающих с приложением БД. В вычислительной сети АБД, как правило, взаимодействует с администратором сети. В обязанности последнего входят контроль за функционированием аппаратнопрограммных средств сети, реконфигурация сети, восстановление программного обеспечения после сбоев и отказов оборудования, профилактические мероприятия и обеспечение разграничения доступа. Вычислительная система (ВС) представляет собой совокупность взаимосвязанных и согласованно действующих ЭВМ или процессоров и других устройств, обеспечивающих автоматизацию процессов приема, обработки и выдачи информации потребителям. Поскольку основными функциями БнД являются хранение и обработка данных, то используемая ВС, наряду с приемлемой мощностью центральных процессоров (ЦП) должна иметь достаточный объем оперативной и внешней памяти прямого доступа. Обслуживающий персонал выполняет функции поддержания технических и программных средств в работоспособном состоянии. Он проводит профилактические, регламентные, восстановительные и другие работы по планам, а также по мере необходимости. 1.2. Архитектура информационной системы Эффективность функционирования информационной системы (ИС) во многом зависит от ее архитектуры. В настоящее время перспективной является архитектура клиент-сервер. В достаточно распространенном варианте она предполагает наличие компьютерной сети и распределенной базы данных, включающей корпоративную базу данных (КБД) и персональные базы данных (ПБД). КБД размещается на компьютересервере, ПБД размещаются на компьютерах сотрудников подразделений, являющихся клиентами корпоративной БД. Сервером определенного ресурса в компьютерной сети называется компьютер (программа), управляющий этим ресурсом, клиентом - компьютер (программа), использующий этот ресурс. В качестве ресурса компьютерной сети могут выступать, к примеру, базы данных, файловые системы, службы печати, почтовые службы. Тип сервера определяется видом ресурса, которым он управляет. Например, если управляемым ресурсом является база данных, то соответствующий сервер называется сервером базы данных. Достоинством организации информационной системы по архитектуре клиентсервер является удачное сочетание централизованного хранения, обслуживания и коллективного доступа к общей корпоративной информации с индивидуальной работой пользователей над персональной информацией. Архитектура клиент-сервер допускает различные варианты реализации. Исторически первыми появились распределенные ИС с применением файлсервера (рис. 1.1). В таких ИС по запросам пользователей файлы базы данных передаются на персональные компьютеры (ПК), где и производится их обработка. Недостатком такого варианта архитектуры является высокая интенсивность передачи обрабатываемых данных. Причем, зачастую передаются избыточные данные: вне зависимости от того, сколько записей из базы данных требуется пользователю, файлы базы данных передаются целиком. Структура распределенной ИС, построенной по архитектуре клиент-сервер с использованием сервера баз данных, показана на рис. 1.2. При такой архитектуре сервер базы данных обеспечивает выполнение основного объема обработки данных. Формируемые пользователем или приложением запросы поступают к серверу БД в виде инструкций языка SQL. Сервер базы данных выполняет поиск и извлечение нужных данных, которые затем передаются на компьютер пользователя. Достоинством такого подхода в сравнении предыдущим является заметно меньший объем передаваемых данных. Основные варианты построения распределенных БД по архитектуре клиент-сервер рассматриваются в разделе 4. Для создания и управления персональными БД и приложений, работающих с ними, используются СУБД, такие как Access и Visual FoxPro фирмы Microsoft, Paradox фирмы Borland. Корпоративная БД создается, поддерживается и функционирует под управлением сервера БД, например, Microsoft SQL Server или Oracle Server. В зависимости от размеров организации и особенностей решаемых задач информационная система может иметь одну из следующих конфигураций: компьютер-сервер, содержащий корпоративную и персональные базы; компьютер-сервер и персональные компьютеры с ПБД; несколько компьютеров-серверов и персональных компьютеров с ПБД. Использование архитектуры клиент-сервер дает возможность постепенного наращивания информационной системы предприятия, во-первых, по мере развития предприятия; во-вторых, по мере развития самой информационной системы. Разделение общей БД на корпоративную БД и персональные БД позволяет уменьшить сложность проектирования БД по сравнению с централизованным вариантом, а значит снизить вероятность ошибок при проектировании и стоимость проектирования. Важнейшим достоинством применения БД в информационных системах является обеспечение независимости данных от прикладных программ. Это дает возможность пользователям не заниматься проблемами представления данных на физическом уровне: размещения данных в памяти, методов доступа к ним и т. д. Такая независимость достигается поддерживаемым СУБД многоуровневым представлением данных в БД на логическом (пользовательском) и физическом уровнях. Благодаря СУБД и наличию логического уровня представления данных обеспечивается отделение концептуальной (понятийной) модели БД от ее физического представления в памяти ЭВМ. 1.3. Системы управления базами данных В этом подразделе приводится классификация СУБД, и рассматриваются основные их функции. В качестве основных классификационных признаков можно использовать следующие: вид программы, характер использования, модель данных. Названные признаки существенно влияют на целевой выбор СУБД и эффективность использования разрабатываемой информационной системы. Классификация СУБД. В общем случае под СУБД можно понимать любой программный продукт, поддерживающий процессы создания, ведения и использования БД. Рассмотрим какие из имеющихся на рынке программ имеют отношение к БД и в какой мере они связаны с базами данных. К СУБД относятся следующие основные виды программ: полнофункциональные СУБД; серверы БД; клиенты БД; средства разработки программ работы с БД. Полнофункциональные СУБД (ПФСУБД) представляют собой традиционные СУБД, которые сначала появились для больших машин, затем для мини-машин и для ПЭВМ. Из числа всех СУБД современные ПФСУБД являются наиболее многочисленными и мощными по своим возможностям. К ПФСУБД относятся, например, такие пакеты как: Clarion Database Developer, DataBase, Dataplex, dBase IV, Microsoft Access, Microsoft FoxPro и Paradox R: BASE. Обычно ПФСУБД имеют развитый интерфейс, позволяющий с помощью команд меню выполнять основные действия с БД: создавать и модифицировать структуры таблиц, вводить данные, формировать запросы, разрабатывать отчеты, выводить их на печать и т. п. Для создания запросов и отчетов не обязательно программирование, а удобно пользоваться языком QBE (Query By Example - формулировки запросов по образцу, см. подраздел 3.8). Многие ПФСУБД включают средства программирования для профессиональных разработчиков. Некоторые системы имеют в качестве вспомогательных и дополнительные средства проектирования схем БД или CASE-подсистемы. Для обеспечения доступа к другим БД или к данным SQL-серверов полнофункциональные СУБД имеют факультативные модули. Серверы БД предназначены для организации центров обработки данных в сетях ЭВМ. Эта группа БД в настоящее время менее многочисленна, но их количество постепенно растет. Серверы БД реализуют функции управления базами данных, запрашиваемые другими (клиентскими) программами обычно с помощью операторов SQL. Примерами серверов БД являются следующие программы: NetWare SQL (Novell), MS SQL Server (Microsoft), InterBase (Borland), SQLBase Server (Gupta), Intelligent Database (Ingress). В роли клиентских программ для серверов БД в общем случае могут использоваться различные программы: ПФСУБД, электронные таблицы, текстовые процессоры, программы электронной почты и т. д. При этом элементы пары "клиент сервер" могут принадлежать одному или разным производителям программного обеспечения. В случае, когда клиентская и серверная части выполнены одной фирмой, естественно ожидать, что распределение функций между ними выполнено рационально. В остальных случаях обычно преследуется цель обеспечения доступа к данным "любой ценой". Примером такого соединения является случай, когда одна из полнофункциональных СУБД играет роль сервера, а вторая СУБД (другого производителя) - роль клиента. Так, для сервера БД SQL Server (Microsoft) в роли клиентских (фронтальных) программ могут выступать многие СУБД, такие как: dBASE IV, Biyth Software, Paradox, DataEase, Focus, 1-2-3, MDBS III, Revelation и другие. Средства разработки программ работы с БД могут использоваться для создания разновидностей следующих программ: клиентских программ; серверов БД и их отдельных компонентов; пользовательских приложений. Программы первого и второго вида довольно малочисленны, так как предназначены, главным образом, для системных программистов. Пакетов третьего вида гораздо больше, но меньше, чем полнофункциональных СУБД. К средствам разработки пользовательских приложений относятся системы программирования, например Clipper, разнообразные библиотеки программ для различных языков программирования, а также пакеты автоматизации разработок (в том числе систем типа клиент-сервер). В числе наиболее распространенных можно назвать следующие инструментальные системы: Delphi и Power Builder (Borland), Visual Basic (Microsoft), SILVERRUN (Computer Advisers Inc.), S-Designor (SDP и Powersoft) и ERwin (LogicWorks). Кроме перечисленных средств, для управления данными и организации обслуживания БД используются различные дополнительные средства, к примеру, мониторы транзакций. По характеру использования СУБД делят на персональные и многопользовательские. Персональные СУ БД обычно обеспечивают возможность создания персональных БД и недорогих приложений, работающих с ними. Персональные СУБД или разработанные с их помощью приложения зачастую могут выступать в роли клиентской части многопользовательской СУБД. К персональным СУБД, например, относятся Visual FoxPro, Paradox, Clipper, dBase, Access и др. Многопользовательские СУБД включают в себя сервер БД и клиентскую часть и, как правило, могут работать в неоднородной вычислительной среде (с разными типами ЭВМ и операционными системами). К многопользовательским СУБД относятся, например, СУБД Oracle и Informix. По используемой модели данных СУБД (как и БД), разделяют на иерархические, сетевые, реляционные, объектно-ориентированные и другие типы. Некоторые СУБД могут одновременно поддерживать несколько моделей данных. С точки зрения пользователя, СУБД реализует функции хранения, изменения (пополнения, редактирования и удаления) и обработки информации, а также разработки и получения различных выходных документов. Для работы с хранящейся в базе данных информацией СУБД предоставляет программам и пользователям следующие два типа языков: язык описания данных - высокоуровневый непроцедурный язык декларативного типа, предназначенный для описания логической структуры данных; язык манипулирования данными - совокупность конструкций, обеспечивающих выполнение основных операций по работе с данными: ввод, модификацию и выборку данных по запросам. Названные языки в различных СУБД могут иметь отличия. Наибольшее распространение получили два стандартизованных языка: QBE (Query By Example) - язык запросов по образцу и SQL (Structured Query Language) - структурированный язык запросов. QBE в основном обладает свойствами языка манипулирования данными, SQL сочетает в себе свойства языков обоих типов - описания и манипулирования данными. Перечисленные выше функции СУБД, в свою очередь, используют следующие основные функции более низкого уровня, которые назовем низкоуровневыми: управление данными во внешней памяти; управление буферами оперативной памяти; управление транзакциями; ведение журнала изменений в БД; обеспечение целостности и безопасности БД. Дадим краткую характеристику необходимости и особенностям реализации перечисленных функций в современных СУБД. Реализация функции управления данными во внешней памяти в разных системах может различаться и на уровне управления ресурсами (используя файловые системы ОС или непосредственное управление устройствами ПЭВМ), и по логике самих алгоритмов управления данными. В основном методы и алгоритмы управления данными являются "внутренним делом" СУБД и прямого отношения к пользователю не имеют. Качество реализации этой функции наиболее сильно влияет на эффективность работы специфических ИС, например, с огромными БД, со сложными запросами, большим объемом обработки данных. Необходимость буферизации данных и как следствие реализации функции управления буферами оперативной памяти обусловлено тем, что объем оперативной памяти меньше объема внешней памяти. Буферы представляют собой области оперативной памяти, предназначенные для ускорения обмена между внешней и оперативной памятью. В буферах временно хранятся фрагменты БД, данные из которых предполагается использовать при обращении к СУБД или планируется записать в базу после обработки. Механизм транзакций используется в СУБД для поддержания целостности данных в базе. Транзакцией называется некоторая неделимая последовательность операций над данными БД, которая отслеживается СУБД от начала и до завершения. Если по какимлибо причинам (сбои и отказы оборудования, ошибки в программ- / ном обеспечении, включая приложение) транзакция остается незавершенной, то она отменяется. Говорят, что транзакции присущи три основных свойства: атомарность (выполняются все входящие в транзакцию операции или ни одна); сериализуемость (отсутствует взаимное влияние выполняемых в одно и то же время транзакций); долговечность (даже крах системы не приводит к утрате результатов зафиксированной транзакции). Примером транзакции является операция перевода денег с одного счета на другой в банковской системе. Здесь необходим, по крайней мере, двухшаговый процесс. Сначала снимают деньги с одного счета, затем добавляют их к другому счету. Если хотя бы одно из действий не выполнится успешно, результат операции окажется неверным и будет нарушен баланс между счетами. Контроль транзакций важен в однопользовательских и в многопользовательских СУБД, где транзакции могут быть запущены параллельно. В последнем случае говорят о сериализуемости транзакций. Под сериализацией параллельно выполняемых транзакций понимается составление такого плана их выполнения (сериального плана), при котором суммарный эффект реализации транзакций эквивалентен эффекту их последовательного выполнения. При параллельном выполнении смеси транзакций возможно возникновение конфликтов (блокировок), разрешение которых является функцией СУБД. При обнаружении таких случаев обычно производится "откат" путем отмены изменений, произведенных одной или несколькими транзакциями. Ведение журнала изменений в БД (журнализация изменений) выполняется СУБД для обеспечения надежности хранения данных в базе при наличии аппаратных сбоев и отказов, а также ошибок в программном обеспечении. Журнал СУБД - это особая БД или часть основной БД, непосредственно недоступная пользователю к используемая для записи информации обо всех изменениях базы данных. В различных СУБД в журнал могут заноситься записи, соответствующие изменениям в СУБД на разных уровнях: от минимальной внутренней операции модификации страницы внешней памяти до логической операции модификации БД (например, вставки записи, удаления столбца, изменения значения в поле) и даже транзакции. Для эффективной реализации функции ведения журнала изменений в БД необходимо обеспечить повышенную надежность хранения и поддержания в рабочем состоянии самого журнала. Иногда для этого в системе хранят несколько копий журнала. Обеспечение целостности БД составляет необходимое условие успешного функционирования БД, особенно для случая использования БД в сетях. Целостность БД, есть свойство базы данных, означающее, что в ней содержится полная, непротиворечивая и адекватно отражающая предметную область информация. Поддержание целостности БД включает проверку целостности и ее восстановление в случае обнаружения противоречий в базе данных. Целостное состояние БД описывается с помощью ограничений целостности в виде условий, которым должны удовлетворять хранимые в базе данные. Примером таких условий может служить ограничение диапазонов возможных значений атрибутов объектов, сведения о которых хранятся в БД, или отсутствие повторяющихся записей в таблицах реляционных БД. Обеспечение безопасности достигается в СУБД шифрованием прикладных программ, данных, защиты паролем, поддержкой уровней доступа к базе данных и к отдельным ее элементам (таблицам, формам, отчетам и т. д.). 1.4. Локальные информационные системы Функциональные части информационной системы могут размещаться на одном или на нескольких компьютерах. Рассмотрим варианты организации И С на одном ПК. Соответствующую ИС обычно называют локальной или однопользовательской (хотя последнее не совсем строго, поскольку на одном компьютере поочередно могут работать несколько пользователей). Более сложные варианты организации ИС рассматриваются в разделе 4. Организация функционирования локальной ИС на одном компьютере в среде некоторой операционной системы (ОС) возможна с помощью следующих вариантов использования программных средств: "полной" СУБД; приложения и "усеченной" (ядра) СУБД; независимого приложения. Первый способ обычно применяется в случаях, когда в дисковой памяти компьютера помещается вся СУБД, и она часто используется для доработки приложения (рис. 1.3). Взаимодействие пользователя с СУБД происходит напрямую через пользовательский (терминальный) интерфейс СУБД, либо с помощью приложения. Приложение выполняется в режиме интерпретации. Основное достоинство схемы - простота разработки и сопровождения БД и приложений при наличии развитых соответствующих средств разработки и сервисных средств. Недостатком этой схемы являются затраты дисковой памяти на хранение программы СУБД. Приложение с ядром СУБД (рис. 1.4) используют для достижения следующих целей: уменьшения объема занимаемого СУБД пространства жесткого диска и оперативной памяти; повышения скорости работы приложения; защиты приложения от модификации со стороны пользователя (обычно ядро не содержит средств разработки приложений). Примером такого подхода является использование модуля FoxRun системы FoxBase+. Из современных СУБД отметим Microsoft Access, включающую дополнительный пакет Microsoft Access Developer's Toolkit. С его помощью можно создавать переносимую на дискетах "укороченную" (run-time) версию Microsoft Access, не содержащую инструментов разработки. Достоинствами использования ядра СУБД по сравнению с использованием полной версии СУБД являются: меньшее потребление ресурсов памяти компьютера, ускорение работы приложения и возможность защиты приложения от модификации. К основным недостаткам можно отнести все еще значительный объем дисковой памяти, необходимой для хранения ядра СУБД, и недостаточно высокое быстродействие работы приложений (выполнение приложения по-прежнему происходит путем интерпретации). При третьем способе организации ИС исходная программа предварительно компилируется - преобразуется в последовательность исполняемых машинных команд. В результате получается готовая к выполнению независимая программа, не требующая для своей работы ни всей СУБД, ни ее ядра (рис. 1.5). Заметим, что с точки зрения выполнения основных функций хранения и обработки данных такая программа мало отличается от приложения, работающего под управлением СУБД или ее ядра. Основными достоинствами этого варианта по сравнению с двумя предыдущими является экономия внешней и оперативной памяти компьютера, ускорение выполнения приложения и полная защита приложения от модификации (случай дизассемблирования и вставки своего кода и ему подобные в расчет не берутся). К недостаткам можно отнести трудоемкость доработки приложений и отсутствие возможности использовать стандартные средства СУБД по обслуживанию БД. 1.5. Способы разработки и выполнения приложений Современные СУБД позволяют решать широкий круг задач по работе с базами данных без разработки приложения. Тем не менее, есть случаи, когда целесообразно разработать приложение. Например, если требуется автоматизация манипуляций с данными, терминальный интерфейс СУБД недостаточно развит, либо имеющиеся в СУБД стандартные функции по обработке информации не устраивают пользователя. Для разработки приложений СУБД должна иметь программный интерфейс, основу которого составляют функции и/или процедуры соответствующего языка программирования. Существующие СУБД поддерживают следующие технологии (и их комбинации) разработки приложений: ручное кодирование программ (Clipper, FoxPro, Paradox); создание текстов приложений с помощью генераторов (FoxApp в FoxPro, Personal Programmer в Paradox); автоматическая генерация готового приложения методами визуального программирования (Delphi, Access, Paradox tor Windows). При ручном кодировании программисты вручную набирают текст программ приложений, после чего выполняют их отладку. Использование генераторов упрощает разработку приложений, поскольку при этом можно получать программный код без ручного набора. Генераторы приложений облегчают разработку основных элементов приложений (меню, экранных форм, запросов и т. д.), но зачастую не могут полностью исключить ручное кодирование. Средства визуального программирования приложений являются дальнейшим развитием идеи использования генераторов приложений. Приложение при этом строится из готовых "строительных блоков" с помощью удобной интегрированной среды. При необходимости разработчик легко может вставить в приложение свой код. Интегрированная среда, как правило, предоставляет мощные средства создания, отладки и модификации приложений. Использование средств визуального программирования позволяет в кратчайшие сроки создавать более надежные, привлекательные и эффективные приложения по сравнению с приложениями, полученными первыми двумя способами. Разработанное приложение обычно состоит из одного или нескольких файлов операционной системы. Если основным файлом приложения является исполняемый файл (например, ехефайл), то это приложение, скорее всего, является независимым приложением, которое выполняется автономно от среды СУБД. Получение независимого приложения на практике осуществляется путем компиляции исходных текстов программ, полученных различными способами: путем набора текста вручную, а также полученных с помощью генератора приложения или среды визуального программирования. Независимые приложения позволяют получать, например, СУБД FoxPro и система визуального программирования Delphi. Отметим, что с помощью средств Delphi обычно независимые приложения не разрабатывают, так как это достаточно трудоемкий процесс, а привлекают процессор баз данных BDE (Borland DataBase Engine), играющий роль ядра СУБД. Одним из первых средств разработки приложений для персональных ЭВМ является система Clipper, представляющая собой "чистый компилятор". Во многих случаях приложение не может исполняться без среды СУБД. Выполнение приложения состоит в том, что СУБД анализирует содержимое файлов приложения (в частном случае - это текст исходной программы) и автоматически строит необходимые исполняемые машинные команды. Другими словами, приложение выполняется методом интерпретации. Режим интерпретации реализован во многих современных СУБД, например, Access, Visual FoxPro и Paradox, а также в СУБД недавнего прошлого, к примеру, FoxBase и FoxPro. Кроме этого, существуют системы, использующие промежуточный вариант между компиляцией и интерпретацией - так называемую псевдокомпиляцию. В таких системах исходная программа путем компиляции преобразуется в промежуточный код (псевдокод) и записывается на диск. В этом виде ее в некоторых системах разрешается даже редактировать, но главная цель псевдокомпиляции - преобразовать программу к виду, ускоряющему процесс ее интерпретации. Такой прием широко применялся в СУБД, работающих под управлением DOS, например, Foxbase+ и Paradox 4.0/4.5 for DOS. В СУБД, работающих под управлением Windows, псевдокод чаще используют для того, чтобы запретить модифицировать приложение. Это полезно для защиты от случайной или преднамеренной порчи работающей программы. Например, такой прием применен в СУБД Paradox for Windows, где допускается разработанные экранные формы и отчеты преобразовывать в соответствующие объекты, не поддающиеся редактированию. Некоторые СУБД предоставляют пользователю возможность выбора варианта разработки приложения: как интерпретируемого СУБД программного кода или как независимой программы. Достоинством применения независимых приложений является то, что время выполнения машинной программы обычно меньше, чем при интерпретации. Такие приложения целесообразно использовать на слабых машинах и в случае установки систем "под ключ", когда необходимо закрыть приложение от доработок со стороны пользователей. Важным достоинством применения интерпретируемых приложений является легкость их модификации. Если готовая программа подвергается частым изменениям, то для их внесения нужна инструментальная система, т. е. СУБД или аналогичная среда. Для интерпретируемых приложений такой инструмент всегда под рукой, что очень удобно. Другим серьезным достоинством систем с интерпретацией является то, что хорошие СУБД обычно имеют мощные средства контроля целостности данных и защиты от несанкционированного доступа, чего не скажешь о системах компилирующего типа. В последних упомянутые функции приходится программировать вручную, либо оставлять на совести администраторов. При выборе средств для разработки приложения следует учитывать три основных фактора: ресурсы компьютера, особенности приложения (потребность в модификации функций программы, время на разработку, необходимость контроля доступа и поддержание целостности информации) и цель разработки (отчуждаемый программный продукт или система автоматизации своей повседневной деятельности). Для пользователя, имеющего современный компьютер и планирующего создать несложное приложение, по всей видимости, больше подойдет СУБД интерпретирующего типа. Напомним, что такие системы достаточно мощны, имеют высокоуровневые средства, удобны для разработки и отладки, позволяют быстро выполнить разработку и обеспечивают удобное сопровождение и модификацию приложения. При использовании компьютера со слабыми характеристиками лучше остановить свой выбор на системе со средствами разработки независимых приложений. При этом следует иметь ввиду, что малейшее изменение в приложении влечет за собой циклическое повторение этапов программирования, компиляции и отладки программы. Разница в выполнении независимого приложения и выполнения приложения в режиме интерпретации колеблется в пределах миллисекунд в пользу независимого приложения. В то же время разница во времени подготовки приложения к его использованию обычно составляет величины порядка минуты - часы в пользу систем с интерпретацией. 1.6. Схема обмена данными при работе с БД Пользователю любой категории (администратору БД, разработчику приложения, обычному пользователю) для грамотного решения задач полезно представлять вычислительный процесс, происходящий в ОС при работе с БД. Раскроем внутренние механизмы этого процесса на примере наиболее общего случая организации ИС, функционирующей на одном ПК, - когда пользователь работает с "полной" версией программы СУБД (рис. 1.3). Варианты, представленные на рис. 1.4 и рис. 1.5, можно считать частными случаями. При работе пользователя с базой данных над ее содержимым выполняются следующие основные операции: выбор, добавление, модификация (замена) и удаление данных. Рассмотрим как происходит обмен данными между отдельным пользователем и персональной СУБД при выполнении наиболее часто используемой операции выбора данных. Обмен данными между пользователем и БД для других операций отличается несущественно. Схематично обмен данными при работе пользователя с БД можно представить так, как показано на рис. 1.6, где обычными стрелками обозначены связи по управлению, утолщенными - связи по информации. Цикл взаимодействия пользователя с БД с помощью приложения можно разделить на следующие основные этапы: 1. Пользователь терминала (1) в процессе диалога с приложением формулирует запрос (2) на некоторые данные из БД. 2. Приложение (3) на программном уровне средствами языка манипулирования данными формулирует запрос (4), с которым обращается к СУБД. 3. Используя свои системные управляющие блоки и таблицы, СУБД с помощью словаря данных определяет местоположение требуемых данных и обращается (5) за ними к ОС. 4. Программы методов доступа файловой системы ОС считывают (6) из внешней памяти искомые данные и помещают их в системные буферы СУБД. 5. Преобразуя полученные данные к требуемому формату, СУБД пересылает их (7) в соответствующую область программы и сигнализирует (8) о завершении операции каким-либо образом (например, кодом возврата). 6. Результаты выбора данных из базы приложение (3) отображает (9) на терминале пользователя (1). В случае работы пользователя в диалоговом режиме с СУБД (без приложения) цикл взаимодействия пользователя с БД упрощается. Его можно представить следующими этапами. 1. Пользователь терминала (10) формулирует на языке запросов СУБД, например QBE, по связи (11) требование на выборку некоторых данных из базы. 2. СУБД определяет местоположение требуемых данных и обращается (5) за ними к ОС, которая считывает (6) из внешней памяти искомые данные и помещает их в системные буферы СУБД. 3. Информация из системных буферов преобразуется (12) к требуемому формату, после чего отображается (13) на терминале пользователя (10). Напомним, что описанная схема поясняет как функционирует СУБД с одним пользователем на отдельной ПЭВМ. Если компьютер и ОС поддерживают многопользовательский режим работы, то в такой вычислительной системе может функционировать многопользовательская СУБД. Последняя, в общем случае, позволяет одновременно обслуживать несколько пользователей, работающих непосредственно с СУБД или с приложениями (каждое из которых может поддерживать работу с одним или несколькими пользователями). Иногда к вычислительной системе подключается так называемый "удаленный пользователь", находящийся на некотором удалении от ЭВМ и соединенный с ней при помощи какой-либо передающей среды (интерфейс ЭВМ, телефонный канал связи, радиоканал, оптико-волоконная линия и т. д.). Чаще всего такой пользователь программным способом эмулируется под обычного локального пользователя. СУБД, как правило, этой подмены "не замечает" и работает по обслуживанию запросов обычным образом. В многопользовательских СУБД при выполнении различных операций параллельно проистекают процессы, подобные описанным выше и показанным на рис. 1.6. При обслуживании нескольких параллельных источников запросов (от пользователей и приложений) СУБД так планирует использование своих ресурсов и ресурсов ЭВМ, чтобы обеспечить независимое или почти независимое выполнение операций, порождаемых запросами. Многопользовательские СУБД часто применяются на больших и средних ЭВМ, где основным режимом использования ресурсов является коллективный доступ. На персональных ЭВМ пользователь обычно работает один, но с различными программами, в том числе и одновременно (точнее, попеременно). Иногда такими программами оказываются СУБД: различные программы или разные копии одной и той же СУБД. Последняя ситуация возникает, например, при работе с различными базами данных с помощью СУБД Access. Технология одновременной работы пользователя с несколькими программами неплохо реализована в Windows. Здесь каждая выполняемая программа имеет свое окно взаимодействия с пользователем, и имеются удобные средства переключения между программами. При работе в Windows СУБД избавлена от необходимости поддержания нескольких сеансов работы с пользователями. Лекция 7 2. Модели и типы данных Хранимые в базе данные имеют определенную логическую структуру - иными словами, описываются некоторой моделью представления данных (моделью данных), поддерживаемой СУБД. К числу классических относятся следующие модели данных: иерархическая, сетевая, реляционная. Кроме того, в последние годы появились и стали более активно внедряться на практике следующие модели данных: постреляционная, многомерная, объектно-ориентированная. Разрабатываются также всевозможные системы, основанные на других моделях данных, расширяющих известные модели. В их числе можно назвать объектнореляционные, дедуктивно-объектно-ориентированные, семантические, концептуальные и ориентированные модели. Некоторые из этих моделей служат для интеграции баз данных, баз знаний и языков программирования. В некоторых СУБД поддерживается одновременно несколько моделей данных. Например, в системе ИНТЕРБАЗА для приложений применяется сетевой язык манипулирования данными, а в пользовательском интерфейсе реализованы языки SQL и QBE. 2.1. Иерархическая модель В иерархической модели связи между данными можно описать с помощью упорядоченного графа (или дерева). Упрощенно представление связей между данными в иерархической модели показано на рис. 2.1. Рис. 2.1. Представление связей в иерархической модели Для описания структуры (схемы) иерархической БД на некотором языке программирования используется тип данных "дерево". Тип "дерево" схож с типами данных "структура" языков программирования ПЛ/1 и Си и "запись" языка Паскаль. В них допускается вложенность типов, каждый из которых находится на некотором уровне. Тип "дерево" является составным. Он включает в себя подтипы ("поддеревья"), каждый из которых, в свою очередь, является типом "дерево". Каждый из типов "дерево" состоит из одного "корневого" типа и упорядоченного набора (возможно пустого) подчиненных типов. Каждый из элементарных типов, включенных в тип "дерево", является простым или составным типом "запись". Простая "запись" состоит из одного типа, например, числового, а составная "запись" объединяет некоторую совокупность типов, например, целое, строку символов и указатель (ссылку). Пример типа "дерево" как совокупности типов показан на рис. 2.2. Корневым называется тип, который имеет подчиненные типы и сам не является подтипом. Подчиненный тип (подтип) является потомком по отношению к типу, который выступает для него в роли предка (родителя). Потомки одного и того же типа являются близнецами по отношению друг к другу. В целом тип "дерево" представляет собой иерархически организованный набор типов "запись". Иерархическая БД представляет собой упорядоченную совокупность экземпляров данных типа "дерево" (деревьев), содержащих экземпляры типа "запись" (записи). Часто отношения родства между типами переносят на отношения между самими записями. Поля записей хранят собственно числовые или символьные значения, составляющие основное содержание БД. Обход всех элементов иерархической БД обычно производится сверху вниз и слева направо. В иерархических СУБД может использоваться терминология, отличающаяся от приведенной. Так, в системе IMS понятию "запись" соответствует термин "сегмент", а под "записью БД" понимается вся совокупность записей, относящаяся к одному экземпляру типа "дерево". Данные в базе с приведенной схемой (рис. 2.2) могут выглядеть, например, как показано на рис. 2.3. Для организации физического размещения иерархических данных в памяти ЭВМ могут использоваться следующие группы методов: представление линейным списком с последовательным распределением памяти (адресная арифметика, левосписковые структуры); представление связными линейными списками (методы, использующие указатели и справочники). К основным операциям манипулирования иерархически организованными данными относятся следующие: поиск указанного экземпляра БД (например, дерева со значением 10 в поле Отд_номер); переход от одного дерева к другому; переход от одной записи к другой внутри дерева (например, к следующей записи типа Сотрудники); вставка новой записи в указанную позицию; удаление текущей записи и т. д. В соответствии с определением типа "дерево", можно заключить, что между предками и потомками автоматически поддерживается контроль целостности связей. Основное правило контроля целостности формулируется следующим образом: потомок не может существовать без родителя, а у некоторых родителей может не быть потомков. Механизмы поддержания целостности связей между записями различных деревьев отсутствуют. К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. Иерархическая модель данных удобна для работы с иерархически упорядоченной информацией. Недостатком иерархической модели является ее громоздкость для обработки информации с достаточно сложными логическими связями, а также сложность понимания для обычного пользователя. На иерархической модели данных основано сравнительно ограниченное количество СУБД, в числе которых можно назвать зарубежные системы IMS, PC/Focus, Team-Up и Data Edge, а также отечественные системы Ока, ИНЭС и МИРИС. 2.2. Сетевая модель Сетевая модель данных позволяет отображать разнообразные взаимосвязи элементов данных в виде произвольного графа, обобщая тем самым иерархическую модель данных (рис. 2.4). Наиболее полно концепция сетевых БД впервые была изложена в Предложениях группы КОДАСИЛ (KODASYL). Рис. 2.4. Представление связей в сетевой модели Для описания схемы сетевой БД используется две группы типов: "запись" и "связь". Тип "связь" определяется для двух типов "запись": предка и потомка. Переменные типа "связь" являются экземплярами связей. Сетевая БД состоит из набора записей и набора соответствующих связей. На формирование связи особых ограничений не накладывается. Если в иерархических структурах запись-потомок могла иметь только одну запись-предка, то в сетевой модели данных запись-потомок может иметь произвольное число записей-предков (сводных родителей). Пример схемы простейшей сетевой БД показан на рис. 2.5. Типы связей здесь обозначены надписями на соединяющих типы записей линиях. Рис. 2.5. Пример схемы сетевой БД Пример схемы сетевой БДВ различных СУБД сетевого типа для обозначения одинаковых по сути понятий зачастую используются различные термины. Например, такие, как элементы и агрегаты данных, записи, наборы, области и т. д. Физическое размещение данных в базах сетевого типа может быть организовано практически теми же методами, что и в иерархических базах данных. К числу важнейших операций манипулирования данными баз сетевого типа можно отнести следующие: поиск записи в БД; переход от предка к первому потомку; переход от потомка к предку; создание новой записи; удаление текущей записи; обновление текущей записи; включение записи в связь; исключение записи из связи; изменение связей и т. д. Достоинством сетевой модели данных является возможность эффективной реализации по показателям затрат памяти и оперативности. В сравнении с иерархической моделью сетевая модель предоставляет большие возможности в смысле допустимости образования произвольных связей. Недостатком сетевой модели данных является высокая сложность и жесткость схемы БД, построенной на ее основе, а также сложность для понимания и выполнения обработки информации в БД обычным пользователем. Кроме того, в сетевой модели данных ослаблен контроль целостности связей вследствие допустимости установления произвольных связей между записями. Системы на основе сетевой модели не получили широкого распространения на практике. Наиболее известными сетевыми СУБД являются следующие: IDMS, db VistaIII, СЕТЬ, СЕТОР и КОМПАС. 2.3. Реляционная модель Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии отношение (relation). Отношение представляет собой множество элементов, называемых кортежами. Подробно теоретическая основа реляционной модели данных рассматривается в следующем разделе. Наглядной формой представления отношения является привычная для человеческого восприятия двумерная таблица. Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам - атрибуты отношения. С помощью одной таблицы удобно описывать простейший вид связей между данными, а именно: деление одного объекта (явления, сущности, системы и проч.), информация о котором хранится в таблице, на множество подобъектов, каждому из которых соответствует строка или запись таблицы. При этом каждый из подобъектов имеет одинаковую структуру или свойства, описываемые соответствующими значениями полей записей. Например, таблица может содержать сведения о группе обучаемых, о каждом из которых известны следующие характеристики: фамилия, имя и отчество, пол, возраст и образование. Поскольку в рамках одной таблицы не удается описать более сложные логические структуры данных из предметной области, применяют связывание таблиц. Физическое размещение данных в реляционных базах на внешних носителях легко осуществляется с помощью обычных файлов. Достоинство реляционной модели данных заключается в простоте, понятности и удобстве физической реализации на ЭВМ. Именно простота и понятность для пользователя явились основной причиной их широкого использования. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми. Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей. Примерами зарубежных реляционных СУБД для ПЭВМ являются следующие: dBaseIII Plus и dBase IY (фирма Ashton-Tate), DB2 (IBM), R:BASE (Microrim), FoxPro ранних версий и FoxBase (Fox Software), Paradox и dBASE for Windows (Borland), FoxPro более поздних версий, Visual FoxPro и Access (Microsoft), Clarion (Clarion Software), Ingres (ASK Computer Systems), Oracle (Oracle). К отечественным СУБД реляционного типа относятся системы: ПАЛЬМА (ИК АН УССР), а также система HyTech (МИФИ). Заметим, что последние версии реляционных СУБД имеют некоторые свойства объектно-ориентированных систем. Такие СУБД часто называют объектнореляционными. Примером такой системы можно считать продукты Oracle 8.x. Системы предыдущих версий вплоть до Oracle 7.x считаются "чисто" реляционными. 2.4. Постреляционная модель Классическая реляционная модель предполагает неделимость данных, хранящихся в полях записей таблиц. Это означает, что информация в таблице представляется в первой нормальной форме (подраздел 5.2). Существует ряд случаев, когда это ограничение мешает эффективной реализации приложений. Постреляционная модель данных представляет собой расширенную реляционную модель, снимающую ограничение неделимости данных, хранящихся в записях таблиц. Постреляционная модель данных допускает многозначные поля - поля, значения которых состоят из подзначений. Набор значений многозначных полей считается самостоятельной таблицей, встроенной в основную таблицу. На рис. 2.6 на примере информации о накладных и товарах для сравнения приведено представление одних и тех же данных с помощью реляционной (а) и постреляционной (б) моделей. Таблица INVOICES (накладные) содержит данные о номерах накладных (INVNO) и номерах покупателей (CUSTNO). В таблице INVOICE.ITEMS (накладные-товары) содержатся данные о каждой из накладных: номер накладной (INVNO), название товара (GOODS) и количество товара (QTY). Таблица INVOICES связана с таблицей INVOICE.ITEMS по полю INVNO. а) INVOICES INVNO CUSTNO 0373 8723 8374 8232 7364 8723 INVOICE.ITEMS INVNO GOODS QTY 0373 Сыр 3 0373 Рыба 2 8374 Лимонад 1 8374 Сок 6 8374 Печенье 2 7364 Йогурт 1 б) INVOICES INVNO CUSTNO GOODS QTY 0373 8723 Сыр 3 0373 Рыба 2 8374 8232 Лимонад 1 8374 Сок 6 8374 Печенье 2 7364 8723 Йогурт 1 Рис. 2.6. Структуры данных реляционной и постреляционной моделей Как видно из рисунка, по сравнению с реляционной моделью в постреляционной модели данные хранятся более эффективно, а при обработке не требуется выполнять операцию соединения данных из двух таблиц. Для доказательства на рис. 2.7 приводятся примеры операторов SELECT выбора данных из всех полей базы на языке SQL для реляционной (а) и постреляционной (б) моделей. Помимо обеспечения вложенности полей постреляционная модель поддерживает ассоциированные многозначные поля (множественные группы). Совокупность ассоциированных полей называется ассоциацией. При этом в строке первое значение одного столбца ассоциации соответствует первым значениям всех других столбцов ассоциации. Аналогичным образом связаны все вторые значения столбцов и т. д. а) SELECT INVOICES.INVNO, CUSTNO, GOODS, QTY FROM INVOICES, INVOICE.ITEMS WHERE INVOICES.INVNO=INVOICE.1TEMS.INVNO; б) SELECT INVNO, CUSTNO, GOODS, QTY FROM INVOICES; Рис. 2.7. Операторы SQL для реляционной и постреляционной моделей На длину полей и количество полей в записях таблицы не накладывается требование постоянства. Это означает, что структура данных и таблиц имеют большую гибкость. Поскольку постреляционная модель допускает хранение в таблицах ненормализованных данных, возникает проблема обеспечения целостности и непротиворечивости данных. Эта проблема решается включением в СУБД механизмов, подобных хранимым процедурам в клиент-серверных системах. Для описания функций контроля значений в полях имеется возможность создавать процедуры (коды конверсии и коды корреляции), автоматически вызываемые до или после обращения к данным. Коды корреляции выполняются сразу после чтения данных, перед их обработкой. Коды конверсии, наоборот, выполняются после обработки данных. Достоинством постреляционной модели является возможность представления совокупности связанных реляционных таблиц одной постреляционной таблицей. Это обеспечивает высокую наглядность представления информации и повышение эффективности ее обработки. Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных. Рассмотренная нами постреляционная модель данных поддерживается СУБД uniVers. К числу других СУБД, основанных на постреляционной модели данных, относятся также системы Bubba и Dasdb. 2.5. Многомерная модель Многомерный подход к представлению данных в базе появился практически одновременно с реляционным, но реально работающих многомерных СУБД (МСУБД) до настоящего времени было очень мало. С середины 90-х годов интерес к ним стал приобретать массовый характер. Толчком послужила в 1993 году программная статья одного из основоположников реляционного подхода Э. Кодда. В ней сформулированы 12 основных требований к системам класса OLAP (Online Analytical Processing - оперативная аналитическая обработка), важнейшие из которых связаны с возможностями концептуального представления и обработки многомерных данных. Многомерные системы позволяют оперативно обрабатывать информацию для проведения анализа и принятия решения. В развитии концепций ИС можно выделить следующие два направления: системы оперативной (транзакционной) обработки; системы аналитической обработки (системы поддержки принятия решений). Реляционные СУБД предназначались для информационных систем оперативной обработки информации и в этой области были весьма эффективны. В системах аналитической обработки они показали себя несколько неповоротливыми и недостаточно гибкими. Более эффективными здесь оказываются многомерные СУБД (МСУБД). Многомерные СУБД являются узкоспециализированными СУБД, предназначенными для интерактивной аналитической обработки информации. Раскроем основные понятия, используемые в этих СУБД: агрегируемость, историчность и прогнозируемость данных. Агрегируемостъ данных означает рассмотрение информации на различных уровнях ее обобщения. В информационных системах степень детальности представления информации для пользователя зависит от его уровня: аналитик, пользователь-оператор, управляющий, руководитель. Историчность данных предполагает обеспечение высокого уровня статичности (неизменности) собственно данных и их взаимосвязей, а также обязательность привязки данных ко времени. Статичность данных позволяет использовать при их обработке специализированные методы загрузки, хранения, индексации и выборки. Временная привязка данных необходима для частого выполнения запросов, имеющих значения времени и даты в составе выборки. Необходимость упорядочения данных по времени в процессе обработки и представления данных пользователю накладывает требования на механизмы хранения и доступа к информации. Так, для уменьшения времени обработки запросов желательно, чтобы данные всегда были отсортированы в том порядке, в котором они наиболее часто запрашиваются. Прогнозируемость данных подразумевает задание функций прогнозирования и применение их к различным временным интервалам. Многомерность модели данных означает не многомерность визуализации цифровых данных, а многомерное логическое представление структуры информации при описании и в операциях манипулирования данными. По сравнению с реляционной моделью многомерная организация данных обладает более высокой наглядностью и информативностью. Для иллюстрации на рис. 2.8 приведены реляционное (а) и многомерное (б) представления одних и тех же данных об объемах продаж автомобилей. Если речь идет о многомерной модели с мерностью больше двух, то не обязательно визуально информация представляется в виде многомерных объектов (трех-, четырех- и более мерных гиперкубов). Пользователю и в этих случаях более удобно иметь дело с двухмерными таблицами или графиками. Данные при этом представляют собой "вырезки" (точнее, "срезы") из многомерного хранилища данных, выполненные с разной степенью детализации. а) Модель Месяц Объем "Жигули" июнь 12 "Жигули" июль 24 "Жигули" август 5 "Москвич" июнь 2 "Москвич" июль 18 "Волга" июль 19 б) Модель "Жигули" Июнь Июль Август 12 24 5 "Москвич" 2 "Волга" N 18 19 N N Рис. 2.8. Реляционное и многомерное представление данных Рассмотрим основные понятия многомерных моделей данных, к числу которых относятся измерение и ячейка. Измерение (Dimension) - это множество однотипных данных, образующих одну из граней гиперкуба. Примерами наиболее часто используемых временных измерений являются Дни, Месяцы, Кварталы и Годы. В качестве географических измерений широко употребляются Города, Районы, Регионы и Страны. В многомерной модели данных измерения играют роль индексов, служащих для идентификации конкретных значений в ячейках гиперкуба. Ячейка (Cell) или показатель - это поле, значение которого однозначно определяется фиксированным набором измерений. Тип поля чаще всего определен как цифровой. В зависимости от того, как формируются значения некоторой ячейки, обычно она может быть переменной (значения изменяются и могут быть загружены из внешнего источника данных или сформированы программно) либо формулой (значения, подобно формульным ячейкам электронных таблиц, вычисляются по заранее заданным формулам). В примере на рис. 2.8(б) каждое значение ячейки Объем продаж однозначно определяется комбинацией временного измерения (Месяц продаж) и модели автомобиля. На практике зачастую требуется большее количество измерений. Пример трехмерной модели данных приведен на рис. 2.9. В существующих МСУБД используются два основных варианта (схемы) организации данных: гиперкубическая и поликубическая. В поликубической схеме предполагается, что в БД может быть определено несколько гиперкубов с различной размерностью и с различными измерениями в качестве граней. Примером системы, поддерживающей поликубический вариант БД, является сервер Oracle Express Server. В случае гиперкубической схемы предполагается, что все показатели определяются одним и тем же набором измерений. Это означает, что при наличии нескольких гиперкубов БД все они имеют одинаковую размерность и совпадающие измерения. Очевидно, в некоторых случаях информация в БД может быть избыточной (если требовать обязательное заполнение ячеек). В случае многомерной модели данных применяется ряд специальных операций, к которым относятся: формирование "среза", "вращение", агрегация и детализация. "Срез" (Slice) представляет собой подмножество гиперкуба, полученное в результате фиксации одного или нескольких измерений. Формирование "срезов" выполняется для ограничения используемых пользователем значений, так как все значения гиперкуба практически никогда одновременно не используются. Например, если ограничить значения измерения Модель автомобиля в гиперкубе (рис. 2.9) маркой "Жигули", то получится двухмерная таблица продаж этой марки автомобиля различными менеджерами по годам. Операция "вращение" (Rotate) применяется при двухмерном представлении данных. Суть ее заключается в изменении порядка измерений при визуальном представлении данных. Так, "вращение" двумерной таблицы, показанной на рис. 2.8(б), приведет к изменению ее вида таким образом, что по оси Х будет марка автомобиля, а по оси Y - время. Операцию "вращение" можно обобщить и на многомерный случай, если под ней понимать процедуру изменения порядка следования измерений. В простейшем случае, например, это может быть взаимная перестановка двух произвольных измерений. Операции "агрегация" (Drill Up) и "детализация" (Drill Down) означают соответственно переход к более общему и к более детальному представлению информации пользователю из гиперкуба. Для иллюстрации смысла операции "агрегация" предположим, что у нас имеется гиперкуб, в котором помимо измерений гиперкуба, приведенного на рис. 2.9, имеются еще измерения: Подразделение, Регион, Фирма, Страна. Заметим, что в этом случае в гиперкубе существует иерархия (снизу вверх) отношений между измерениями: Менеджер, Подразделение, Регион, Фирма, Страна. Пусть в описанном гиперкубе определено, насколько успешно в 1995 году менеджер Петров продавал автомобили "Жигули" и "Волга". Тогда, поднимаясь на уровень выше по иерархии, с помощью операции "агрегация" можно выяснить, как выглядит соотношение продаж этих же моделей на уровне подразделения, где работает Петров. Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных, связанных со временем. При организации обработки аналогичных данных на основе реляционной модели происходит нелинейный рост трудоемкости операций в зависимости от размерности БД и существенное увеличение затрат оперативной памяти на индексацию. Недостатком многомерной модели данных является ее громоздкость для простейших задач обычной оперативной обработки информации. Примерами систем, поддерживающими многомерные модели данных, являются Essbase (Arbor Software), Media Multi-matrix (Speedware), Oracle Express Server (Oracle) и Cache (InterSystems). Некоторые программные продукты, например Media/ MR (Speedware), позволяют одновременно работать с многомерными и с реляционными БД. В СУБД Cache, в которой внутренней моделью данных является многомерная модель, реализованы три способа доступа к данным: прямой (на уровне узлов многомерных массивов), объектный и реляционный. 2.6. Объектно-ориентированная модель В объектно-ориентированной модели при представлении данных имеется возможность идентифицировать отдельные записи базы. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования. Стандартизованная объектно-ориентированной модель описана в рекомендациях стандарта ODMG-93 (Object Database Management Group - группа управления объектноориентированными базами данных). Реализовать в полном объеме рекомендации ODMG93 пока не удается. Для иллюстрации ключевых идей рассмотрим несколько упрощенную модель объектно-ориентированной БД. Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым - string) или типом, конструируемым пользователем (определяется как class). Значением свойства типа string является строка символов. Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объектэкземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов. Пример логической структуры объектно-ориентированной БД библиотечного дела приведен на рис. 2.10. Здесь объект типа- БИБЛИОТЕКА является родительским для объектовэкземпляров классов АБОНЕНТ, КАТАЛОГ и ВЫДАЧА. Различные объекты типа КНИГА могут иметь одного или разных родителей. Объекты типа КНИГА, имеющие одного и того же родителя, должны различаться по крайней мере инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn, удк, название и автор. Логическая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД. Основное отличие между ними состоит в методах манипулирования данными. Для выполнения действий над данными в рассматриваемой модели БД применяются логические операции, усиленные объектно-ориентированными механизмами инкапсуляции, наследования и полиморфизма. Ограниченно могут применяться операции, подобные командам SQL (например, для создания БД). Создание и модификация БД сопровождается автоматическим формированием и последующей корректировкой индексов (индексных таблиц), содержащих информацию для быстрого поиска данных. Рассмотрим кратко понятия инкапсуляции, наследования и полиморфизма применительно к объектно-ориентированной модели БД. Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, если в объект типа КАТАЛОГ добавить свойство, задающее телефон автора книги и имеющее название телефон, то мы получим 2 Зак.925. одноименные свойства у объектов АБОНЕНТ и КАТАЛОГ. Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано. Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа КНИГА, являющимся потомками объекта типа КАТАЛОГ, можно приписать свойства объекта-родителя: isbn, удк, название и автор. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств билет и номер в объекте БИБЛИОТЕКА приводит к наследованию этих свойств всеми дочерними объектами АБОНЕНТ, КНИГА и ВЫДАЧА. Не случайно поэтому значения свойства билет классов АБОНЕНТ и ВЫДАЧА, показанных на рисунке, будут одинаковыми - 00015. Полиморфизм в объектно-ориентированных языках программирования означает способность одного и того же программного кода работать с разнотипными данными. Другими словами, он означает допустимость в объектах разных типов иметь методы (процедуры или функции) с одинаковыми именами, Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента. Применительно к нашей объектно-ориентированной БД полиморфизм означает, что объекты класса КНИГА, имеющие разных родителей из класса КАТАЛОГ, могут иметь разный набор свойств. Следовательно, программы работы с объектами класса КНИГА могут содержать полиморфный код. Поиск в объектно-ориентированной БД состоит в выяснении сходства между объектом, задаваемым пользователем, и объектами, хранящимися в БД. Определяемый пользователем объект, называемый объектом-целью (свойство объекта имеет тип goal), в общем случае может представлять собой подмножество всей хранимой в БД иерархии объектов. Объект-цель, а также результат выполнения запроса могут храниться в самой базе. Пример запроса о номерах читательских билетов и именах абонентов, получавших в библиотеке хотя бы одну книгу, показан на рис. 2.11. Основным достоинством объектно-ориентированной модели данных в сравнении с реляционной является возможность отображения информации о сложныхсвязях объектов. Объектно-ориентированная модель данных позволяет идентифицировать отдельную запись базы данных и определять функции их обработки. Недостатками объектно-ориентированной модели являются высокая понятийная сложность, неудобство обработки данных и низкая скорость выполнения запросов. В 90-е годы существовали экспериментальные прототипы объектноориентированных систем управления базами данных. В настоящее время такие системы получили широкое распространение, в частности, к ним относятся следующие СУБД: РОЕТ (РОЕТ Software), Jasmine (Computer Associates), Versant (Versant Technologies), 02 (Ardent Software), ODB-Jupiter (научно-производственный центр "Интелтек Плюс"), а также Iris, Orion и Postgres. 2.7. Типы данных Первоначально СУБД применялись преимущественно для решения финансовоэкономических задач. При этом, независимо от модели представления, в базах данных использовались следующие основные типы данных: числовые. Примеры значений данных: 0.43, 328, 2Е+5; символьные (алфавитно-цифровые). Примеры значений данных: "пятница", "строка", "программист"; даты, задаваемые с помощью специального типа "Дата" или как обычные символьные данные. Примеры значений данных: 1.12.97, 23/2/1999. В разных СУБД эти типы могли несущественно отличаться друг от друга по названию, диапазону значений и виду представления. Впоследствии в новых областях применения стали появляться специализированные системы обработки данных, например, геоинформационные, обработки видеоизображений и т. д. В связи с этим разработчики стали вводить в традиционные СУБД новые типы данных. К числу сравнительно новых типов данных можно отнести следующие: временные и дата-временные, предназначенные для хранения информации о времени и/или дате. Примеры значений данных: 31.01.85 (дата), 9:10:03 (время), 6.03.1960 12:00 (дата и время); символьные переменной длины, предназначенные для хранения текстовой информации большой длины, например, документа; двоичные, предназначенные для хранения графических объектов, аудио- и видеоинформации, пространственной, хронологической и другой специальной информации. Например, в MS Access таким типом является тип данных "Поле объекта OLE", который позволяет хранить в БД графические данные в формате BMP (Bitmap) и автоматически их отображать при работе с БД; гиперссылки (hyperlinks), предназначенные для хранения ссылок на различные ресурсы (узлы, файлы, документы и т. д.), находящиеся вне базы данных, например, в сети Internet, корпоративной сети intranet или на жестком диске компьютера. Примеры значений данных: http:\\www.chat.ru, ftp:\\chance4u.teens.com. В современных СУБД с различными моделями данных могут использоваться все перечисленные типы данных. Лекция 8 3. Реляционная модель данных В разделе рассматривается наиболее распространенная реляционная модель представления данных. Даются определение реляционной модели и характеристика ее элементов. Описываются индексирование, связывание таблиц и контроль целостности связей. Рассматриваются теоретические основы построения языков запросов: реляционная алгебра и реляционное исчисление. Дается характеристика языков QBE и SQL, формат операторов и примеры построения запросов с их помощью. 3.1. Определение реляционной модели Реляционная модель данных (РМД) некоторой предметной области представляет собой набор отношений, изменяющихся во времени. При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними. Элементы РМД и формы их представления приведены в табл. 3.1. Элемент реляционной модели Форма представления Отношение Таблица Схема отношения Строка заголовков столбцов таблицы (заголовок таблицы) Кортеж Строка таблицы Сущность Описание свойств объекта Атрибут Заголовок столбца таблицы Домен Множество допустимых значений атрибута Значение атрибута Значение поля в записи Первичный ключ Один или несколько атрибутов Тип данных Тип значений элементов таблицы Таблица 3.1 Элементы реляционной модели Отношение является важнейшим понятием и представляет собой двумерную таблицу, содержащую некоторые данные. Сущность есть объект любой природы, данные о котором хранятся в базе данных. Данные о сущности хранятся в отношении. Атрибуты представляют собой свойства, характеризующие сущность. В структуре таблицы каждый атрибут именуется и ему соответствует заголовок некоторого столбца таблицы. Математически отношение можно описать следующим образом. Пусть даны n множеств Dl, D2, D3,..., Dn, тогда отношение R есть множество упорядоченных кортежей , где dk € Dk, dk - атрибут, a Dk - домен отношения R. На рис. 3.1 приведен пример представления отношения СОТРУДНИК. В общем случае порядок кортежей в отношении, как и в любом множестве, не определен. Однако в реляционных СУБД для удобства кортежи все же упорядочивают. Чаще всего для этого выбирают некоторый атрибут, по которому система автоматически сортирует кортежи по возрастанию или убыванию. Если пользователь не назначает атрибута упорядочения, система автоматически присваивает номер кортежам в порядке их ввода. Формально, если переставить атрибуты в отношении, то получается новое отношение. Однако в реляционных БД перестановка атрибутов не приводит к образованию нового отношения. Домен представляет собой множество всех возможных значений определенного атрибута отношения. Отношение СОТРУДНИК включает 4 домена. Домен 1 содержит фамилии всех сотрудников, домен 2 - номера всех отделов фирмы, домен 3 - названия всех должностей, домен 4 - даты рождения всех сотрудников. Каждый домен образует значения одного типа данных, например, числовые или символьные. Отношение СОТРУДНИК содержит 3 кортежа. Кортеж рассматриваемого отношения состоит из 4-х элементов, каждый из которых выбирается из соответствующего домена. Каждому кортежу соответствует строка таблицы (рис. 3.1). Схема отношения (заголовок отношения) представляет собой список имен атрибутов. Например, для приведенного примера схема отношения имеет вид СОТРУДНИК (ФИО, Отдел, Должность, Д_Рождения). Множество собственно кортежей отношения часто называют содержимым (телом) отношения. Первичным ключом (ключом отношения, ключевым атрибутом) называется атрибут отношения, однозначно идентифицирующий каждый из его кортежей. Например, в отношении СОТРУДНИК (ФИО, Отдел, Должность, Д_Рождения) ключевым является атрибут "ФИО". Ключ может быть составным (сложным), т. е. состоять из нескольких атрибутов. Каждое отношение обязательно имеет комбинацию атрибутов, которая может служить ключом. Ее существование гарантируется тем, что отношение - это множество, которое не содержит одинаковых элементов - кортежей. Т. е. в отношении нет повторяющихся кортежей, а это значит, что, по крайней мере, вся совокупность атрибутов обладает свойством однозначной идентификации кортежей отношения. Во многих СУБД допускается создавать отношения, не определяя ключи. Возможны случаи, когда отношение имеет несколько комбинаций атрибутов, каждая из которых однозначно определяет все кортежи отношения. Все эти комбинации атрибутов являются возможными ключами отношения. Любой из возможных ключей может быть выбран как первичный. Если выбранный первичный ключ состоит из минимально необходимого набора атрибутов, говорят, что он является не избыточным. Ключи обычно используют для достижения следующих целей: 1) исключения дублирования значений в ключевых атрибутах (остальные атрибуты в расчет не принимаются); 2) упорядочения кортежей. Возможно упорядочение по, возрастанию или убыванию значений всех ключевых атрибутов, а также смешанное упорядочение (по одним возрастание, а по другим - убывание); 3) ускорения работы к кортежами отношения; 4) организации связывания таблиц. Пусть в отношении R1 имеется не ключевой атрибут А, значения которого являются значениями ключевого атрибута В другого отношения R2. Тогда говорят, что атрибут А отношения R1 есть внешний ключ. С помощью внешних ключей устанавливаются связи между отношениями. Например, имеются два отношения СТУДЕНТ (ФИО, Группа, Специальность) и ПРЕДМЕТ (Назв.Пр., Часы), которые связаны отношением СТУДЕНТ_ПРЕДМЕТ (ФИО, . Назв.Пр. Оценка) (рис. 3.2). В связующем отношении атрибуты ФИО и Назв.Пр образуют составной ключ. Эти атрибуты представляют собой внешние ключи, являющиеся первичными ключами других отношений. Реляционная модель накладывает на внешние ключи ограничение для обеспечения целостности данных, называемое ссылочной целостностью. Это означает, что каждому значению внешнего ключа должны соответствовать строки в связываемых отношениях. Поскольку не всякой таблице можно поставить в соответствие отношение, приведем условия, выполнение которых позволяет таблицу считать отношением. 1. Все строки таблицы должны быть уникальны, т. е. не может быть строк с одинаковыми первичными ключами. 2. Имена столбцов таблицы должны быть различны, а значения их простыми, т. е. недопустима группа значений в одном столбце одной строки. 3. Все строки одной таблицы должны иметь одну структуру, соответствующую именам и типам столбцов. 4. Порядок размещения строк в таблице может быть произвольным. Наиболее часто таблица с отношением размещается в отдельном файле. В некоторых СУБД одна отдельная таблица (отношение) считается базой данных. В других СУБД база данных может содержать несколько таблиц. В общем случае можно считать, что БД включает одну или несколько таблиц, объединенных смысловым содержанием, а также процедурами контроля целостности и обработки информации в интересах решения некоторой прикладной задачи. Например, при использовании СУБД Microsoft Access в файле БД наряду с таблицами хранятся и другие объекты базы: запросы, отчеты, формы, макросы и модули. Таблица данных обычно хранится на магнитном диске в отдельном файле операционной системы, поэтому по ее именованию могут существовать ограничения. Имена полей хранятся внутри таблиц. Правила их формирования определяются СУБД, которые, как правило, на длину полей и используемый алфавит серьезных ограничений не накладывают. Если задаваемое таблицей отношение имеет ключ, то считается, что таблица тоже имеет ключ, и ее называют ключевой или таблицей с ключевыми полями. У большинства СУБД файл таблицы включает управляющую часть (описание типов полей, имена полей и другая информация) и область размещения записей. К отношениям можно применять систему операций, позволяющую получать одни отношения из других. Например, результатом запроса к реляционной БД может быть новое отношение, вычисленное на основе имеющихся отношений. Поэтому можно разделить обрабатываемые данные на хранимую и вычисляемую части. Основной единицей обработки данных в реляционных БД является отношение, а не отдельные его кортежи (записи). 3.2. Индексирование Как отмечалось выше, определение ключа для таблицы означает автоматическую сортировку записей, контроль отсутствия повторений значений в ключевых полях записей и повышение скорости выполнения операций поиска в таблице. Для реализации этих функций в СУБД применяют индексирование. Термин "индекс" тесно связан с понятием "ключ", хотя между ними есть и некоторое отличие. Под индексом понимают средство ускорения операции поиска записей в таблице, а следовательно, и других операций, использующих поиск: извлечение, модификация, сортировка и т. д. Таблицу, для которой используется индекс, называют индексированной. Индекс выполняет роль оглавления таблицы, просмотр которого предшествует обращению к записям таблицы. В некоторых системах, например Paradox, индексы хранятся в индексных файлах, хранимых отдельно от табличных файлов. Варианты решения проблемы организации физического доступа к информации зависят в основном от следующих факторов: вида содержимого в поле ключа записей индексного файла; типа используемых ссылок (указателей) на запись основной таблицы; метода поиска нужных записей. В поле ключа индексного файла можно хранить значения ключевых полей индексируемой таблицы либо свертку ключа (так называемый хеш-код). Преимущество хранения хеш-кода вместо значения состоит в том, что длина свертки независимо от длины исходного значения ключевого поля всегда имеет некоторую постоянную и достаточно малую величину (например, 4 байта), что существенно снижает время поисковых операций. Недостатком хеширования является необходимость выполнения операции свертки (требует определенного времени), а также борьба с возникновением коллизий (свертка различных значений может дать одинаковый хеш-код). Для организации ссылки на запись таблицы могут использоваться три типа адресов: абсолютный (действительный); относительный; символический (идентификатор). На практике чаще всего используются два метода поиска: последовательный; бинарный (основан на делении интервала поиска пополам). Проиллюстрируем организацию индексирования таблиц двумя схемами: одноуровневой и двухуровневой. При этом примем ряд предположений, обычно выполняемых в современных вычислительных системах Пусть ОС поддерживает прямую организацию данных на магнитных дисках, основные таблицы и индексные файлы хранятся в отдельных файлах. Информация файлов хранится в виде совокупности блоков фиксированного размера, например, целого числа кластеров. При одноуровневой схеме в индексном файле хранятся короткие записи, имеющие два поля: поле содержимого старшего ключа (хеш-кода ключа) адресуемого блока и поле адреса начала этого блока (рис. 3 3). В каждом блоке записи располагаются в порядке возрастания значения ключа или свертки. Старшим ключом каждого блока является ключ его последней записи. Если в индексном файле хранятся хеш-коды ключевых полей индексированной таблицы, то алгоритм поиска нужной записи (с указанным ключом) в таблице включает в себя следующие три этапа. 1. Образование свертки значения ключевого поля искомой записи. 2. Поиск в индексном файле записи о блоке, значение первого поля которого больше полученной свертки (это гарантирует нахождение искомой свертки в этом блоке). 3. Последовательный просмотр записей блока до совпадения сверток искомой записи и записи блока файла. В случае коллизий сверток ищется запись, значение ключа которой совпадает со значением ключа искомой записи. Основным недостатком одноуровневой схемы является то, что ключи (свертки) записей хранятся вместе с записями. Это приводит к увеличению времени поиска записей из-за большой длины просмотра (значения данных в записях приходится пропускать). Двухуровневая схема в ряде случаев оказывается более рациональной, в ней ключи (свертки) записей отделены от содержимого записей (рис. 3.4). В этой схеме индекс основной таблицы распределен по совокупности файлов: одному файлу главного индекса и множеству файлов с блоками ключей. На практике для создания индекса для некоторой таблицы БД пользователь указывает поле таблицы, которое требует индексации. Ключевые поля таблицы во многих СУБД как правило индексируются автоматически. Индексные файлы, создаваемые по ключевым полям таблицы, часто называются файлами первичных индексов. Индексы, создаваемые пользователем для не ключевых полей, иногда называют вторичными (пользовательскими) индексами. Введение таких индексов не изменяет физического расположения записей таблицы, но влияет на последовательность просмотра записей. Индексные файлы, создаваемые для поддержания вторичных индексов таблицы, обычно называются файлами вторичных индексов. Связь вторичного индекса с элементами данных базы может быть установлена различными способами. Один из них - использование вторичного индекса как входа для получения первичного ключа, по которому затем с использованием первичного индекса производится поиск необходимых записей (рис. 3.5). Некоторыми СУБД, например Access, деление индексов на первичные и вторичные не производится. В этом случае используются автоматически создаваемые индексы и индексы, определяемые пользователем по любому из не ключевых полей. Главная причина повышения скорости выполнения различных операций в индексированных таблицах состоит в том, что основная часть работы производится с небольшими индексными файлами, а не с самими таблицами. Наибольший эффект повышения производительности работы с индексированными таблицами достигается для значительных по объему таблиц. Индексирование требует небольшого дополнительного места на диске и незначительных затрат процессора на изменение индексов в процессе работы. Индексы в общем случае могут изменяться перед выполнением запросов к БД, после выполнения запросов к БД, по специальным командам пользователя или программным вызовам приложений. 3.3. Связывание таблиц При проектировании реальных БД информацию обычно размещают в нескольких таблицах. Таблицы при этом связаны семантикой информации. В реляционных СУБД для указания связей таблиц производят операцию их связывания. Укажем выигрыш, обеспечиваемый в результате связывания таблиц. Многие СУБД при связывании таблиц автоматически выполняют контроль целостности вводимых в базу данных в соответствии с установленными связями. В конечном итоге это повышает достоверность хранимой в БД информации. Кроме того, установление связи между таблицами облегчает доступ к данным. Связывание таблиц при выполнении таких операций как поиск, просмотр, редактирование, выборка и подготовка отчетов обычно обеспечивает возможность обращения к, произвольным полям связанных записей. Это уменьшает количество явных обращений к таблицам данных и число манипуляций в каждой из них. Основные виды связи таблиц Между таблицами могут устанавливаться бинарные (между двумя таблицами), тернарные (между тремя таблицами) и, в общем случае, n-арные связи. Рассмотрим наиболее часто встречающиеся бинарные связи. При связывании двух таблиц выделяют основную и дополнительную (подчиненную) таблицы. Логическое связывание таблиц производится с помощью ключа связи. Ключ связи, по аналогии с обычным ключом таблицы, состоит из одного или нескольких полей, которые в данном случае называют полями связи (ПС). Суть связывания состоит в установлении соответствия полей связи основной и дополнительной таблиц. Поля связи основной таблицы могут быть обычными и ключевыми. В качестве полей связи подчиненной таблицы чаще всего используют ключевые поля. В зависимости от того, как определены поля связи основной и дополнительной таблиц (как соотносятся ключевые поля с полями связи), между двумя таблицами в общем случае могут устанавливаться следующие четыре основные вида связи (табл. 3.2): один - один (1:1); один - много (1:М); много - один (М:1); много - много (М:М или M:N). Характеристика полей связи по видам 1:1 1:М М:1 М:М Поля связи основной таблицы являются ключом являются ключом не являются ключом не являются ключом не являются ключом не являются ключом Таблица 3.2 Характеристика видов связей таблиц Поля связи дополнительной таблицы являются ключом являются ключом Дадим характеристику названным видам связи между двумя таблицами и приведем примеры их использования. Связь вида 1:1 Связь вида 1:1 образуется в случае, когда все поля связи основной и дополнительной таблиц являются ключевыми. Поскольку значения в ключевых полях обеих таблиц не повторяются, обеспечивается взаимнооднозначное соответствие записей из этих таблиц. Сами таблицы, по сути, здесь становятся равноправными. На практике связи вида 1:1 используются сравнительно редко, так как хранимую в двух таблицах информацию легко объединить в одну таблицу, которая занимает гораздо меньше места в памяти ЭВМ. Возможны случаи, когда удобнее иметь не одну, а две и более таблицы. Причинами этого может быть необходимость ускорить обработку, повысить удобство работы нескольких пользователей с общей информацией, обеспечить более высокую степень защиты информации и т. д. Связь вида 1:М Связь 1:М имеет место в случае, когда одной записи основной таблицы соответствует несколько записей вспомогательной таблицы. Связь вида М:1 Связь М:1 имеет место в случае, когда одной или нескольким записям основной таблицы ставится в соответствие одна запись дополнительной таблицы. Связь вида М:М Самый общий вид связи М:М возникает в случаях, когда нескольким записям основной таблицы соответствует несколько записей дополнительной таблицы. Замечание На практике в связь обычно вовлекается сразу несколько таблиц. При этом одна из таблиц может иметь различного рода связи с несколькими таблицами. В случаях, когда связанные таблицы, в свою очередь, имеют связи с другими таблицами, образуется иерархия или дерево связей. 3.4. Контроль целостности связей Из перечисленных видов связи наиболее широко используется связь вида 1:М. Связь вида 1:1 можно считать частным случаем связи 1:М, когда одной записи главной таблицы соответствует одна запись вспомогательной таблицы. Связь М:1, по сути, является "зеркальным отображением" связи 1:М. Оставшийся вид связи М:М характеризуется как слабый вид связи или даже как отсутствие связи. Поэтому в дальнейшем рассматривается связь вида 1:М. Напомним, что при образовании связи вида 1:М одна запись главной таблицы (главная, родительская запись) оказывается связанной с несколькими записями дополнительной (дополнительные, подчиненные записи) и имеет место схема, показанная на рис. 3.6. Контроль целостности связей обычно означает анализ содержимого двух таблиц на соблюдение следующих правил: каждой записи основной таблицы соответствует нуль или более записей дополнительной таблицы; в дополнительной таблице нет записей, которые не имеют родительских записей в основной таблице; каждая запись дополнительной таблицы имеет только одну родительскую запись основной таблицы. Опишем действие контроля целостности при манипулировании данными в таблицах. Рассмотрим три основные операции над данными двух таблиц: ввод новых записей, модификацию записей, удаление записей. При рассмотрении попытаемся охватить все возможные методы организации контроля целостности. В реальных СУБД могут применяться собственные методы, подобные описываемым. При вводе новых записей возникает вопрос определения последовательности ввода записей в таблицы такой, чтобы не допустить нарушение целостности. Исходя из приведенных правил, логичной является схема, при которой данные сначала вводятся в основную таблицу, а потом - в дополнительную. Очередность ввода может быть установлена на уровне целых таблиц или отдельных записей (случай одновременного ввода в несколько открытых таблиц). В процессе заполнения основной таблицы контроль значений полей связи ведется как контроль обычного ключа (на совпадение со значениями тех же полей других записей). Заполнение полей связи дополнительной таблицы контролируется на предмет совпадения со значениями полей связи основной таблицы. Если вновь вводимое значение в поле связи дополнительной таблицы не совпадет ни с одним соответствующим значением в записях основной таблицы, то ввод такого значения должен блокироваться. Модификация записей. Изменение содержимого полей связанных записей, не относящихся к полям связи, очевидно, должно происходить обычным образом. Нас будет интересовать механизм изменения полей связи. При редактировании полей связи дополнительной таблицы очевидным требованием является то, чтобы новое значение поля связи совпадало с соответствующим значением какой-либо записи основной таблицы. Т. е. дополнительная запись может сменить родителя, но остаться без него не должна. Редактирование поля связи основной таблицы разумно подчинить одному из cледующих правил: редактировать записи, у которых нет подчиненных записей. Если есть подчиненные записи, то блокировать модификацию полей связи; изменения в полях связи основной записи мгновенно передавать во все поля связи всех записей дополнительной таблицы (каскадное обновление). В операциях удаления записей связанных таблиц большую свободу, очевидно, имеют записи дополнительной таблицы. Удаление их должно происходить практически бесконтрольно. Удаление записей основной таблицы логично подчинить одному из следующих правил: удалять можно запись, которая не имеет подчиненных записей; запретить (блокировать) удаление записи при наличии подчиненных записей, либо удалять ее вместе со всеми подчиненными записями (каскадное удаление). 3.5. Теоретические языки запросов Операций, выполняемые над отношениями, можно разделить на две группы. Первую группу составляют операции над множествами, к которым относятся операции: объединения; пересечения; разности; деления; декартова произведения. Вторую группу составляют специальные операции над отношениями, к которым, в частности, относятся операции: проекции, соединения, выбора. В различных СУБД реализована некоторая часть операций над отношениями, определяющая в какой-то мере возможности данной СУБД и сложность реализации запросов к БД. В реляционных СУБД для выполнения операций над отношениями используются две группы языков, имеющие в качестве своей математической основы теоретические языки запросов, предложенные Э.Коддом: реляционная алгебра; реляционное исчисление. Эти языки представляют минимальные возможности реальных языков манипулирования данными в соответствии с реляционной моделью и эквивалентны друг другу по своим выразительным возможностям. Существуют не очень сложные правила преобразования запросов между ними. В реляционной алгебре операнды и результаты всех действий являются отношениями. Языки реляционной алгебры являются процедурными, так как отношение, являющееся результатом запроса к реляционной БД, вычисляется при выполнении последовательности реляционных операторов, применяемым к отношениям. Операторы состоят из операндов, в роли которых выступают отношения, и реляционных операций. Результатом реляционной операции является отношение. Языки исчислений, в отличие от реляционной алгебры, являются непроцедурными (описательными, или декларативными) и позволяют выражать запросы с помощью предиката первого порядка (высказывания в виде функции), которому должны удовлетворять кортежи или домены отношений. Запрос к БД, выполненный с использованием подобного языка, содержит лишь информацию о желаемом результате. Для этих языков характерно наличие наборов правил для записи запросов. В частности, к языкам этой группы относится SQL. 3.6. Реляционная алгебра Реляционная алгебра как теоретический язык запросов по сравнению с реляционным исчислением более наглядно описывает выполняемые над отношениями действия. Примером языка запросов, основанного на реляционной алгебре, является ISBL (Information System Base Language - базовый язык информационных систем). Языки запросов, построенные на основе реляционной алгебры, в современных СУБД широкого распространения не получили. Однако знакомство с ней полезно для понимания сути реляционных операций, выражаемых другими используемыми языками. Вариант реляционной алгебры, предложенный Коддом, включает в себя следующие основные операции: объединение, разность (вычитание), пересечение, декартово (прямое) произведение (или произведение), выборка (селекция, ограничение), проекция, деление и соединение. Упрощенное графическое представление этих операций приведено на рис. 3.8. По справедливому замечанию Дейта, реляционная алгебра Кодда обладает несколькими недостатками. Во-первых, восемь перечисленных операций по охвату своих функций, с одной стороны, избыточны, так как минимально необходимый набор составляют пять операций: объединение, вычитание, произведение, проекция и выборка. Три другие операции (пересечение, соединение и деление) можно определить через пять минимально необходимых. Так, например, соединение - это проекция выборки произведения. Во-вторых, этих восьми операций недостаточно для построения реальной СУБД на принципах реляционной алгебры. Требуются расширения, включающие операции: переименования атрибутов, образования новых вычисляемых атрибутов, вычисления итоговых функций, построения сложных алгебраических выражений, присвоения, сравнения и т. д. Рассмотрим перечисленные операции более подробно, сначала - операции реляционной алгебры Кодда, а затем - дополнительные операции, введенные Дейтом. Операции реляционной алгебры Кодда можно разделить на две группы: базовые теоретико-множественные и специальные реляционные. Первая группа операций включает в себя классические операции теории множеств: объединение, разность, пересечение и произведение. Вторая группа представляет собой развитие обычных теоретико-множественных операций в направлении к реальным задачам манипулирования данными, в ее состав входят следующие операции: проекция, селекция, деление и соединение. Операции реляционной алгебры могут выполняться над одним отношением (например, проекция) или над двумя отношениями (например, объединение). В первом случае операция называется унарной, а во втором - бинарной. При выполнении бинарной операции участвующие в операциях отношения должны быть совместимы по структуре. Совместимость структур отношений означает совместимость имен атрибутов и типов соответствующих доменов. Частным случаем совместимости является идентичность (совпадение). Для устранения конфликтов имен атрибутов в исходных отношениях (когда совпадение имен недопустимо), а также для построения произвольных имен атрибутов результирующего отношения применяется операция переименования атрибутов. Структура результирующего отношения по определенным правилам наследует свойства структур исходных отношений. В большинстве рассматриваемых бинарных реляционных операций будем считать, что заголовки исходных отношений идентичны, так как в этом случае не возникает проблем с заголовком результирующего отношения (в общем случае, заголовки могут не совпадать, тогда нужно оговаривать правила формирования заголовка отношения-результата). Основные правила записи выражений. Как отмечалось, результатом произвольной реляционной операции является отношение, которое, в свою очередь, может участвовать в другой реляционной операции. Это свойство реляционной алгебры называется свойством замкнутости. Свойство замкнутости позволяет записывать вложенные выражения реляционной алгебры, основой которых выступают рассмотренные ранее элементарные операций: объединение; проекция; пересечение; выборка; и т. д. При записи произвольного выражения реляционной алгебры надо принимать во внимание следующее: 1. В реляционной алгебре должен быть определен приоритет выполнения операций (например, операция пересечение более приоритетна чем операция объединение), который нужно учитывать при записи выражений. Для изменения порядка выполнения операций в выражениях можно использовать круглые скобки. 2. Существуют тождественные преобразования, позволяющие по-разному записывать одно и то же выражение. 3. Составляя выражение, нужно обеспечивать совместимость участвующих в операциях отношений. При необходимости изменения заголовков следует выполнять переименование атрибутов. 3.7. Структурированный язык запросов SQL Структурированный язык запросов SQL основан на реляционном исчислении с переменными кортежами. Язык имеет несколько стандартов, наиболее распространенными из которых являются SQL-89 и SQL-92. Общая характеристика языка Язык SQL предназначен для выполнения операций над таблицами (создание, удаление, изменение структуры) и над данными таблиц (выборка, изменение, добавление и удаление), а также некоторых сопутствующих операций. SQL является непроцедурным языком и не содержит операторов управления, организации подпрограмм, ввода-вывода и т. п. В связи с этим SQL автономно не используется, обычно он погружен в среду встроенного языка программирования СУБД (например, FoxPro СУБД Visual FoxPro, ObjectPAL СУБД Paradox, Visual Basic for Applications СУБД Access). В современных СУБД с интерактивным интерфейсом можно создавать запросы, используя другие средства, например QBE. Однако применение SQL зачастую позволяет повысить эффективность обработки данных в базе. Например, при подготовке запроса в среде Access можно перейти из окна Конструктора запросов (формулировки запроса по образцу на языке QBE) в окно с эквивалентным оператором SQL. Подготовку нового запроса путем редактирования уже имеющегося в ряде случае проще выполнить путем изменения оператора SQL. В различных СУБД состав операторов SQL может несколько отличаться. Язык SQL не обладает функциями полноценного языка разработки, а ориентирован на доступ к данным, поэтому его включают в состав средств разработки программ. В этом случае его называют встроенным SQL. Стандарт языка SQL поддерживают современные реализации следующих языков программирования: PL/I, Ada, С, COBOL, Fortran, MUMPS и Pascal. В специализированных системах разработки приложений типа клиент-сервер среда программирования, кроме того, обычно дополнена коммуникационными средствами (установление и разъединение соединений с серверами БД, обнаружение и обработка возникающих в сети ошибок и т. д.), средствами разработки пользовательских интерфейсов, средствами проектирования и отладки. Различают два основных метода использования встроенного SQL: статический; динамический. При статическом использовании языка (статический SQL) в тексте программы имеются вызовы функций языка SQL, которые жестко включаются в выполняемый модуль после компиляции. Изменения в вызываемых функциях могут быть на уровне отдельных параметров вызовов с помощью переменных языка программирования. При динамическом использовании языка (динамический SQL) предполагается динамическое построение вызовов SQL-функций и интерпретация этих вызовов, например, обращение к данным удаленной базы, в ходе выполнения программы. Динамический метод обычно применяется в случаях, когда в приложении заранее неизвестен вид SQL-вызова и он строится в диалоге с пользователем. Основным назначением языка SQL (как и других языков для работы с базами данных) является подготовка и выполнение запросов. В результате выборки данных из одной или нескольких таблиц может быть получено множество записей, называемое: представлением. Представление по существу является таблицей, формируемой в результате выполнения запроса. Можно сказать, что оно является разновидностью хранимого запроса. По одним и тем же таблицам можно построить несколько представлений. Само представление описывается путем указания идентификатора представления и запроса, который должен быть выполнен для его получения. Для удобства работы с представлениями в язык SQL введено понятие курсора. Курсор представляет собой своеобразный указатель, используемый для перемещения по наборам записей при их обработке. Описание и использование курсора в языке SQL выполняется следующим образом. В описательной части программы выполняют связывание переменной типа курсор (CURSOR) с оператором SQL (обычно с оператором SELECT). В выполняемой;, части программы производится открытие курсора (OPEN <имя курсора>), перемещение курсора по записям (FETCH <имя курсора>...), сопровождаемое соответствующей обработкой, и, наконец, закрытие курсора (CLOSE <имя курсора>). Лекция 9 4. Информационные системы в сетях Создание и применение информационных систем в сетях компьютеров, с одной стороны дает заметные преимущества, с другой стороны, вызывает ряд проблем. В частности, возникают проблемы администрирования и защиты информации. В разделе рассматриваются основные понятия, связанные с сетями компьютеров и информационными системами в них, варианты архитектуры клиент-сервер, управление данными и доступ к ним, особенности информационных систем в локальных сетях, Internet и intranet. 4.1. Основные понятия Основные понятия сетей ЭВМ раскроем, рассматривая виды и состав сетей, используемое программное и аппаратное обеспечение, а также методы управления ресурсами. Виды и состав сетей Сетью называется совокупность компьютеров или рабочих станций (PC), объединенных средствами передачи данных. Средства передачи данных, в свою очередь, в общем случае могут состоять из следующих элементов: связных компьютеров, каналов связи (спутниковых, телефонных, цифровых, волоконно-оптических, радио- и / других), коммутирующей аппаратуры, ретрансляторов, различного рода преобразователей сигналов и других элементов и устройств. Современные сети можно классифицировать по различным признакам: по удаленности компьютеров, топологии, назначению, перечню предоставляемых услуг, принципам управлений (централизованные и децентрализованные), методам коммутации (без коммутации, телефонная коммутация, коммутация цепей, сообщений, пакетов и дейтаграмм), видам среды передачи и т.д. В зависимости от удаленности компьютеров сети условно разделяют на локальные и глобальные. Произвольная глобальная сеть может включать другие глобальные сети, локальные сети, а также отдельно подключаемые к ней компьютеры (удаленные компьютеры) или отдельно подключаемые устройства ввода-вывода. Глобальные сети различают четырех основных видов: городские, региональные, национальные и транснациональные. В качестве устройств ввода-вывода могут использоваться, например, печатающие и копирующие устройства, кассовые и банковские аппараты, дисплеи (терминалы) и факсы. Перечисленные элементы сети могут быть удалены друг от друга на значительное расстояние. Примером глобальной сети служит одна из первых в мире сеть ARPANET, а также сеть Интернет В локальных вычислительных сетях (ЛВС) компьютеры расположены на расстоянии до нескольких километров и обычно соединены при помощи скоростных линий связи со скоростью обмена от 1 до 10 и более Мбитов/с (не исключается соединение компьютеров и с помощью низкоскоростных телефонных линий). ЛВС обычно развертываются в рамках некоторой организации (корпорации, учреждения). Поэтому их иногда называют корпоративными системами или сетями. Компьютеры при этом, как правило, находятся в пределах одного помещения, здания или соседних зданий. В глобальной сети основным видом взаимодействия между независимыми компьютерами является обмен сообщениями. Более интенсивный обмен информацией происходит в локальных сетях. В них, по существу, организовано управление аппаратнопрограммными ресурсами всех входящих в сеть компьютеров. Реализует эти функции сетевое ПО. Вкратце остановимся на программно-аппаратных ресурсах и методах управления ими в ЛВС. Программное обеспечение ЛВС Независимо от того, в какой сети работает некоторый компьютер, функции установленного на нем программного обеспечения условно можно разделить на две группы: управление ресурсами самого компьютера (в том числе и в интересах решения задач для других компьютеров); управление обменом с другими компьютерами (сетевые функции). Собственными ресурсами компьютера традиционно управляет ОС. Функции сетевого управления реализует сетевое ПО, которое может быть выполнено как в виде отдельных пакетов сетевых программ, так и виде сетевой ОС (СОС). При разработке сетевого ПО используется иерархический подход, предполагающий определение совокупности сравнительно независимых уровней и интерфейсов между ними. Это позволяет легко модифицировать алгоритмы программ произвольного уровня без существенного изменения других уровней. В общем случае допускается упрощение функций некоторого уровня или даже его полная ликвидация. Для упорядочения разработки сетевого ПО и обеспечения возможности взаимодействия любых вычислительных систем, Международная Организация по Стандартизации (International Organization for Standardization - ISO) разработала Эталонную Модель взаимодействия открытых систем (Open System Interconnection Reference model - модель OSI). Эталонная Модель определяет следующие семь функциональных уровней: физический (physical layer); канальный или управления линией (звеном) передачи (data link); сетевой (network layer); транспортный (transport layer); сеансовый (session layer); представительный (presentation layer); прикладной или уровень приложений (application layer). Отличия сетей друг от друга вызваны особенностями используемого аппаратного и программного обеспечения, различной интерпретацией рекомендаций фирмамиразработчиками, различием требований к системе со стороны решаемых задач (требования защищенности информации, скорости обмена, безошибочности передачи данных и т.д.) и другими причинами. В сетевом ПО локальных сетей часто наблюдается сокращение числа реализуемых уровней. Аппаратные средства ЛВС Основными аппаратными компонентами ЛВС являются: рабочие станции, серверы, интерфейсные платы и кабели. Рабочие станции (PC) - это, как правило, персональные ЭВМ, которые являются рабочими местами пользователей сети. Иногда в PC, непосредственно подключенной к сетевому кабелю, могут отсутствовать накопители на магнитных дисках. Такие PC называют бездисковыми рабочими станциями. Основным преимуществом бездисковых PC является низкая стоимость, а также высокая защищенность от несанкционированного проникновения в систему пользователей и компьютерных вирусов. Недостаток бездисковой PC заключается в невозможности работать в автономном режиме (без подключения к серверу) и иметь собственные архивы данных и программ. Серверы в ЛВС выполняют функции распределения сетевых ресурсов. Обычно его функции возлагают на достаточно мощный ПК, мини-ЭВМ, большую ЭВМ или специальную ЭВМ-сервер. В одной сети может быть один или несколько серверов. Каждый из серверов может быть отдельным или совмещенным с PC. В последнем случае только часть ресурсов сервера оказывается общедоступной. При наличии в ЛВС нескольких серверов, каждый из них управляет работой подключенных к нему PC. Совокупность компьютеров сервера и относящихся к нему PC часто называют доменом. Иногда в одном домене находится несколько серверов. Обычно один из них является главным, а другие - выполняют роль резерва (на случай отказа главного сервера) или логического расширения основного сервера. Используемые сетевые адаптеры имеют три основные характеристики: тип шины компьютера, к которому они подключаются (ISA, EISA, Micro Channel и пр.), разрядность (8, 16, 32, 64) и используемый метод доступа к сетевому каналу данных. Существуют различные схемы объединения компьютеров в ЛВС. Классическими считаются топологии "звезда", "кольцо" и "общая шина". Наиболее широко используются следующие стандартизованные методы доступа к сетевому каналу: Ethernet (поддерживает шинную топологию); Arcnet (поддерживает звездную топологию); Token-Ring (поддерживает кольцевую топологию). Конфигурация соединения элементов в сеть (топология) во многом определяет такие важнейшие характеристики сети, как ее надежность, производительность, стоимость, защищенность и т.д. Одним из подходов к классификации топологий ЛВС является выделение двух основных классов топологий: широковещательных; последовательных. В широковещательных конфигурациях каждый персональный компьютер передает сигналы, которые могут быть восприняты остальными компьютерами. К таким конфигурациям относятся топологии "общая шина", "дерево", "звезда с пассивным центром". Сеть типа "звезда с пассивным центром" можно рассматривать как разновидность "дерева", имеющего корень с ответвлением к каждому подключенному устройству. В последовательных конфигурациях каждый физический подуровень передает информацию одному компьютеру. Примерами последовательных конфигураций являются: произвольная (произвольное соединение компьютеров), иерархическая, "кольцо", "цепочка", "звезда с интеллектуальным центром", "снежинка". Для соединения компьютеров в ЛВС чаще всего используют коаксиальный кабель (тонкий и толстый). Помимо коаксиального кабеля может применяться "витая пара" и оптоволокно. В последнее время ведутся интенсивные работы по разработке и внедрению беспроводных радиосетей. Известные системы на их основе, по сравнению с кабельными системами, пока значительно уступают по скорости передачи данных и дальности приема (сотни метров), но позволяют создавать мобильные распределенные системы. К дополнительному оборудованию ЛВС относят источники бесперебойного питания, модемы, трансиверы, повторители, а также различные разъемы (коннекторы, терминаторы). Принципы управления Существует два основных метода (принципа) управления в ЛВС: централизованное ; децентрализованное. В централизованных сетях одна или несколько ПЭВМ являются центральными, а остальные - рабочими станциями (PC). Центральный узел сети, часто называемый компьютером-сервером (КС), может находиться на отдельном компьютере или совмещаться с PC. В первом случае говорят о выделенном КС, а во втором - о совмещенном КС. Основное назначение КС - управление передачей данных в сети и хранение файлов, используемых многими PC. Исходя из этого, под КС обычно выделяют наиболее производительную и имеющую значительную память ПЭВМ. Кроме того, к КС обычно подключается дорогостоящее оборудование (лазерные принтеры, факсы, модемы, сканеры и т. д.). Существует множество сетевых ОС, реализующих централизованное управление. Среди них Microsoft Windows NT Server, Novell NetWare (версии З.Х и 4.Х), Microsoft Lan Manager, OS/2 Warp Server Advanced, VINES 6.0 и другие. Преимуществом централизованных сетей является высокая защищенность сетевых ресурсов от несанкционированного доступа, удобство администрирования сети, возможность создания сетей с большим числом узлов. Основной недостаток состоит в уязвимости системы при нарушении работоспособности файл-сервера (это преодолевается при наличии нескольких серверов или принятии других мер), а также в предъявлении довольно высоких требований к ресурсам серверов. Сети с децентрализованным управлением (одноранговые сети) не содержат КС. В них функции управления сетью в соответствии с некоторой дисциплиной поочередно передаются от одной PC к другой. Децентрализованное управление, как правило, применяется в сетях со слабыми компьютерами и простейшими обменами между ними" на уровне файлов, а также без серьезного контроля прав доступа к ресурсам сети. Основные ресурсы всех PC обычно оказываются общедоступными, хотя система не всегда обеспечивает корректное их совместное использование на прикладном уровне. Наиболее распространенными программными продуктами, позволяющими строить одноранговые сети, являются следующие программы и пакеты: Novell NetWare Lite, Windows for Workgroups, Windows 95/98, Artisoft LANtastic, LANsmart, Invisible Software NET-30 и другие. Развертывание одноранговой сети для небольшого числа PC часто позволяет построить более эффективную и живучую распределенную вычислительную среду. Сетевое программное обеспечение в них является более простым по сравнению с централизованными сетями. Здесь не требуется установка файл-сервера (компьютера и соответствующих программ), что существенно удешевляет систему. Однако, такие сети слабее с точки зрения защиты информации и администрирования. Говоря о сетях, часто используют термины "сервер" и "клиент". Любое взаимодействие в сети предполагает как минимум два элемента: потребляющий и предоставляющий ресурсы (сервис или услуги). Потребитель ресурсов называется клиентом, а предоставляющий ресурсы компонент - сервером (см. раздел 1). Основными видами ресурсов являются следующие: аппаратные (целая ЭВМ, дисковый накопитель, устройство печати и т. д.), программные и информационные. Если в качестве ресурса рассматривается вся ЭВМ, то говорят о компьютереклиенте и компьютере-сервере. Если подразумевается некоторый аппаратный ресурс, то используют такие термины как: диск-сервер (файловый сервер или файл-сервер), сервер печати. Типичными клиентами в сетях являются: ЭВМ, пользователь или программа. Возможно уточнение назначения компьютера при обработке информации. Тогда говорят о серверах сообщений (обработка поступающих сообщений), серверах БД (обработка запросов к БД), серверах приложений (выполнение приложений пользователя) и т. д. Иногда одним термином называют разные (аппаратные, программные или аппаратно-программные) компоненты вычислительной системы. Так, сервером печати может служить компьютер с подключенным к нему принтером, программа печати или компьютер с программным обеспечением управления печатью. 4.2. Модели архитектуры клиент-сервер При построении распределенных ИС, работающих с БД, широко используется архитектура клиент-сервер. Ее основу составляют принципы организации взаимодействия клиента и сервера при управлении БД. Один из вариантов архитектуры клиент-сервер рассмотрен в подразделе 1.2. Чтобы охарактеризовать основные схемы взаимодействия процессов управления БД, воспользуемся Эталонной моделью Архитектуры открытых систем OSI. Согласно этой модели, функция управления БД относится к прикладному уровню. Остановимся на двух самых верхних уровнях: прикладном и представительном, которые в наибольшей степени являются предметом внимания со стороны разработчика и пользователя. Остальные функции будем считать связными функциями, необходимыми для реализации двух первых. При этом будем придерживаться широкого толкования термина СУБД, понимая под ним все программные системы, которые используют информацию из БД. Как поддерживающая интерфейс с пользователем программа, СУБД, в общем случае, реализует следующие основные функции: управление данными, находящимися в базе; обработка информации с помощью прикладных программ; представление информации в удобном для пользователя виде. Если система размещается на одной ЭВМ, то все функции собраны в одной программе и вызываются по схеме, подобной рассмотренной в разделе 1. При размещении СУБД в сети возможны различные варианты распределение функций по узлам. В зависимости от числа узлов сети, между которыми выполняется распределение функций СУБД, можно выделить двухзвенные модели, трехзвенные модели и т. д. Место разрыва функций соединяется коммуникационными функциями (средой передачи информации в сети). Двухзвенные модели распределения функций Двухзвенные модели соответствуют распределению функций СУБД между двумя узлами сети. Компьютер (узел сети), на котором обязательно присутствует функция управления данными, назовем компьютером-сервером. Компьютер, близкий к, пользователю и обязательно занимающийся вопросами представления информации, назовем компьютером-клиентом. Наиболее типичными вариантами разделения функций между компьютеромсервером и компьютером-клиентом являются следующие: распределенное представление; удаленное представление; распределенная функция; удаленный доступ к данным; распределенная БД. Перечисленные способы распределения функций в системах с архитектурой клиент-сервер иллюстрируют различные варианты: от мощного сервера, когда практически вся работа производится на нем, до мощного клиента, когда большая часть функций выполняется на рабочей станции, а сервер обрабатывает поступающие к нему по сети SQL-вызовы. В моделях удаленного доступа к данным и удаленного представления производится строгое распределение функций между компьютером-клиентом и компьютером-сервером. В других моделях имеет место выполнение одной из следующих функций одновременно на двух компьютерах: управления данными (модель распределенной БД), обработки информации (модель распределенной функции), представления информации (модель распределенного представления). Рассмотрим сначала модели удаленного доступа к данным и удаленного представления (сервера БД) как наиболее широко распространенные. В модели удаленного доступа к данным (Remote Data Access - RDA) программы, реализующие функции представления информации и логику прикладной обработки, совмещены и выполняются на компьютере-клиенте. Обращение за сервисом управления данными происходит через среду передачи с помощью операторов языка SQL или вызовом функций специальной библиотеки API (Application Programming Interface интерфейса прикладного программирования). Основное достоинство RDA-модели состоит в большом обилии готовых СУБД, имеющих SQL-ннтерфейсы, и существующих инструментальных средств, обеспечивающих быстрое создание программ клиентской части. Средства разработки чаще всего поддерживают графический интерфейс пользователя в MS Windows, стандарт интерфейса ODBC и средства автоматической генерации кода. Подавляющее большинство средств разработки использует языки четвертого поколения. Недостатками RDA-модели являются, во-первых, довольно высокая загрузка системы передачи данных вследствие того, что вся логика сосредоточена в приложении, а обрабатываемые данные расположены на удаленном узле. Как увидим далее, во время работы приложений обычно по сети передаются целые БД. Во-вторых, системы, построенные на основе модели RDA, неудобны с точки зрения разработки, модификации и сопровождения. Основная причина состоит в том, что в получаемых приложениях прикладные функции и функции представления тесно взаимосвязаны. Поэтому даже при незначительном изменении функций системы требуется переделка всей прикладной ее части, усложняющая разработку и модификацию системы. Модель сервера БД (DataBase Server - DBS) отличается от предыдущей модели тем, что функции компьютера-клиента ограничиваются функциями представления информации, в то время как прикладные функции обеспечиваются приложением, находящимся на компьютере-сервере. Эта модель является более технологичной, чем RDA-модель и применяется в таких СУБД, как Ingress, Sybase и Oracle. При этом приложения реализуются в виде хранимых процедур. Процедуры обычно хранятся в словаре БД и разделяются несколькими клиентами. В общем случае хранимые процедуры могут выполняться в режимах компиляции и интерпретации. Достоинствами модели DBS являются: возможность хорошего централизованного администрирования приложений на этапах разработки, сопровождения и модификации, а также эффективное использование вычислительных и коммуникационных ресурсов. Последнее достигается за счет того, что выполнение программ в режиме коллективного пользования требует существенно меньших затрат на пересылку данных в сети. Один из недостатков модели DBS связан с ограничениями средств разработки хранимых процедур. Основное ограничение - сильная привязка операторов хранимых процедур к конкретной СУБД. Язык написания хранимых процедур, по сути, является процедурным расширением языка SQL, и не может соперничать по выразительным средствам и функциональным возможностям с традиционными языками третьего поколения, такими, как С и Pascal. Кроме того, в большинстве СУБД нет удовлетворительных средств отладки и тестирования хранимых процедур, что делает их механизм опасным инструментом - неотлаженные программы могут приводить к некорректностям БД, зависаниям серверных и клиентских программ во время работы системы и т. п. Другим недостатком DBS-модели является низкая эффективность использования вычислительных ресурсов ЭВМ, поскольку не удается организовать управление входным потоком запросов к программам компьютера-сервера, а также обеспечить перемещение процедур на другие компьютеры-серверы. В модели распределенного представления имеется мощный компьютер-сервер, а клиентская часть системы практически вырождена. Функцией клиентской части является просто отображение информации на экране монитора и связь с основным компьютером через локальную сеть. СУБД подобного рода могут иметь место в сетях, поддерживающих работу так называемых Х-терминалов. В них основной компьютер (хост-машина) должен иметь достаточную мощность, чтобы обслуживать несколько Х-терминалов. X-терминал тоже должен обладать достаточно быстрым процессором и иметь достаточный объем оперативной памяти (дисковые накопители отсутствуют). Часто Х-терминалы создают на базе RISC-компьютеров (restricted [reduced] instruction set computer) - компьютеров с сокращенным набором команд. Все программное обеспечение находится на хост-машине. Программное обеспечение Х-терминала, выполняющее функции управления представлением и сетевые функции, загружается по сети с сервера при включении Хтерминала. Модель распределенного представления имели СУБД ранних поколений, которые работали на малых, средних и больших ЭВМ. В роли Х-терминалов выступали дисплейные станции и абонентские пункты (локальные и удаленные). В этом случае основную часть функций представления информации реализовывали сами СУБД, а окончательное построение изображении на терминалах пользователя выполнялось на оконечных устройствах. По модели распределенного представления построены системы обслуживания пользователей БД в гетерогенной (неоднородной) среде. Серверная часть таких систем обычно обеспечивает некоторый унифицированный интерфейс, а клиентские части реализуют функции учета специфики оконечного оборудования или преобразования одного формата представления информации в другой. Модель распределенного представления реализует централизованную схему управления вычислительными ресурсами. Отсюда следуют ее основные достоинства простота обслуживания и управления доступом к системе и относительная дешевизна (ввиду невысокой стоимости оконечных терминалов). Недостатками модели являются уязвимость системы при невысокой надежности центрального узла, а также высокие требования к серверу но производительности при большом числе клиентов. В модели распределенной функции логика обработки данных распределена по двум узлам. Такую модель могут иметь ИС, в которых общая часть прикладных функций реализована на компьютере-сервере, а специфические функции обработки информации выполняются на компьютере-клиенте. Функции общего характера могут включать в себя стандартное обеспечение целостности данных, например, в виде хранимых процедур, а оставшиеся прикладные функции реализуют специальную прикладную обработку. Подобную модель имеют также ИС, использующие информацию из нескольких неоднородных БД. Модель распределенной БД предполагает использование мощного компьютераклиента, причем данные хранятся на компьютере-клиенте и на компьютере-сервере. Взаимосвязь обеих баз данных может быть двух разновидностей: а) в локальной и удаленной базах хранятся отдельные части единой БД; б) локальная и удаленная БД являются синхронизируемыми друг с другом копиями. Достоинством модели распределенной БД является гибкость создаваемых па ее основе ИС, позволяющих компьютеру-клиенту обрабатывать локальные и удаленные БД. При наличии механизмов координации соответствия копий система в целом, кроме того, обладает высокой живучестью, так как разрыв соединения клиента и сервера не приводит к краху системы, а ее работа может быть восстановлена с возобновлением соединения. К недостатку модели можно отнести высокие затраты при выполнении большого числа одинаковых приложений на компьютерах-клиентах. Трехзвенная модель распределения функций Трехзеенная модель распределения функций представляет собой типовой вариант, при котором каждая из трех функций приложения реализуется на отдельном компьютере. Варианты распределения функций приложения на большее число компьютеров могут иметь место, но ввиду их редкого применения рассматриваться не будут. Согласно трехзвенной AS-модели, отвечающий за организацию диалога с конечным пользователем процесс, как обычно, реализует функции представления информации и взаимодействует с компонентом приложения так же, как в модели DBS. Компонент приложения, располагаясь на отдельном компьютере, в свою очередь, связано компонентом управления данными подобно модели RDA. Центральным звеном AS-модели является сервер приложений. На сервере приложений реализуется несколько прикладных функций, каждая из которых оформлена как служба предоставления услуг всем требующим этого программам. Серверов приложений может быть несколько, причем каждый из них предоставляет свой вид сервиса. Любая программа, запрашивающая услугу у сервера приложений, является для него клиентом. Поступающие от клиентов к серверам запросы помещаются в очередь, из которой выбираются в соответствии с некоторой дисциплиной, например, по приоритетам. Компонент, реализующий функции представления и являющийся клиентом для сервера приложений, в этой модели трактуется более широко, чем обычно. Он может служить для организации интерфейса с конечным пользователем, обеспечивать прием данных от устройств, например, датчиков, или быть произвольной программой. Достоинством AS-модели является гибкость и универсальность вследствие разделения функций приложения на три независимые составляющие. Во многих случаях эта модель оказывается более эффективной по сравнению с двухзвенными. Основной недостаток модели - более высокие затраты ресурсов компьютеров на обмен информацией между компонентами приложения по сравнению с двухзвенными моделями. Сложные схемы взаимодействия Возможны более сложные схемы взаимодействия, например, схемы, в которых элемент, являющийся сервером для некоторого клиента, в свою очередь, выступает в роли клиента по отношению к другому серверу (рис. 4 3). Пример этого мы наблюдали в ASмодели. Возможно также, что в распределенной вычислительной системе при работе с БД имеются множественные связи (статические), когда один объект по отношению к одним является клиентом, а но отношению к другим - сервером. При рассмотрении взаимодействия объектов в динамике получаются еще более сложные схемы взаимодействия. Примером такой схемы является случай, когда в процессе работы роли объектов меняются: объект, являющийся в некоторый момент времени клиентом по отношению к другому объекту, в последующем становится сервером для другого объекта. 4.3. Управление распределенными данными С управлением данными в распределенных системах связаны следующие две группы проблем: поддержка соответствия БД вносимым изменениям и обеспечение совместного доступа нескольких пользователей к общим данным. Поддержка соответствия БД вносимым изменениям В современных распределенных системах информация может храниться централизовано или децентрализовано. В первом случае проблемы идентичности представления информации для всех пользователей не существует, так как все последние изменения хранятся в одном месте. На практике чаще информация изменяется одновременно в нескольких узлах распределенной вычислительной системы. В этом случае возникает проблема контроля за всеми изменениями информации и предоставления ее в достоверном виде всем пользователям. Существуют две основные технологии децентрализованного управления БД: распределенных БД (Distributed Database); тиражирования, или репликации, БД (Data Replication). Распределенная БД состоит из нескольких фрагментов, размещенных на разных узлах сети и, возможно, управляемых разными СУБД. С точки зрения программ и пользователей, обращающихся к распределенной БД, последняя воспринимается как единая локальная БД. Информация о местоположении каждой из частей распределенной БД и другая служебная информация хранится в так называемом глобальном словаре данных. В общем случае этот словарь может храниться на одном из узлов или тоже быть распределенным. Для обеспечения корректного доступа к распределенной БД в современных системах чаще всего применяется протокол (метод) двухфазной фиксации транзакций (two-phase commit). Суть этого метода состоит в двухэтапной синхронизации выполняемых изменений на всех задействованных узлах. На первом этапе в узлах сети производятся изменения (пока обратимые) в их БД, о чем посылаются уведомления компоненту системы, управляющему обработкой распределенных транзакций. На втором этапе, получив от всех узлов сообщения о правильности выполнения операций (что свидетельствует об отсутствии сбоев и отказов аппаратно-программного обеспечения), управляющий компонент выдает всем узлам команду фиксации изменений. После этого транзакция считается завершенной, а ее результат необратимым. Основным достоинством модели распределенной БД является то, что пользователи всех узлов (при исправных коммуникационных средствах) получают информацию с учетом всех последних изменений. Второе достоинство состоит в экономном использовании внешней памяти компьютеров, что позволяет организовывать БД больших объемов. К недостаткам модели распределенной БД относится следующее: жесткие требования к производительности и надежности каналов связи, а также большие затраты коммуникационных и вычислительных ресурсов из-за их связывания на все время выполнения транзакций. При интенсивных обращениях к распределенной БД, большом числе взаимодействующих узлов, низкоскоростных и ненадежных каналах связи обработка запросов по этой схеме становится практически невозможной. Модель тиражирования данных, в отличие от технологии распределенных БД, предполагает дублирование данных (создание точных копий) в узлах сети. Данные всегда обрабатываются как обычные локальные. Поддержку идентичности копий друг другу в асинхронном режиме обеспечивает компонент системы, называемый репликатором (replicator). При этом между узлами сети могут передаваться как отдельные изменения, так и группы изменений. В течение некоторого времени копии БД могут отличаться друг от друга. К основным достоинствам модели тиражирования БД (в сравнении с предыдущей моделью) относятся: более высокая скорость доступа к данным, так как они всегда есть в узле; существенное уменьшение передаваемого по каналам связи потока информации, поскольку происходит передача не всех операций доступа к данным, а только изменений в БД; повышение надежности механизмов доступа к распределенным данным, поскольку нарушение связи не приводит к потере работоспособности системы (предполагается буферизация потока изменений, позволяющая корректно возобновить работу после восстановления связи). Основной недостаток модели тиражирования БД заключается в том, что на некотором интервале времени возможно "расхождение" копий БД. Если отмеченный недостаток некритичен для прикладных задач, то предпочтительно иметь схему с тиражированием БД. Доступ к общим данным При обслуживании обращений к общим данным средства управления БД должны обеспечивать по крайней мере два основных метода доступа: монопольный и коллективный. Основными объектами доступа в различных системах могут быть целиком БД, отдельные таблицы, записи, поля записей. В СУБД, предоставляющих возможность разработки, объектами доступа также могут выступать спецификации отчетов и экранных форм, запросы и программы. Монопольный доступ обычно используется в двух случаях: во-первых, когда требуется исключить доступ к объектам со стороны других пользователей (например, при работе с конфиденциальной информацией); во-вторых, когда производятся ответственные операции с БД, не допускающие других действий, например, изменение структуры БД. В первом случае пользователь с помощью диалоговых средств СУБД или прикладной программы устанавливает явную блокировку. Во втором случае пользователь тоже может установить явную блокировку, либо положиться на СУБД. Последняя обычно автоматически устанавливает неявную (без ведома пользователя или приложения) блокировку, если это необходимо. В режиме коллективного доступа полная блокировка на используемые объекты как правило, не устанавливается. Коллективный доступ возможен, например, при одновременном просмотре таблиц. Попытки получить монопольный доступ к объектам коллективного доступа должны быть пресечены. Например, в ситуации, когда один или несколько пользователей просматривают таблицу, а другой пользователь собирается удалить эту же таблицу. Для организации коллективного доступа в СУБД применяется механизм блокировок. Суть блокировки состоит в том, что на время выполнения какой-либо операции в БД доступ к используемому объекту со стороны других потребителей временно запрещается или ограничивается. Например, при копировании таблицы она блокируется от изменения, хотя и разрешено просматривать ее содержимое. Рассмотрим некоторый типичный набор блокировок. В конкретных программах схемы блокирования объектов могут отличаться от описываемой. Выделим четыре вида блокировок, перечисленные в порядке убывания строгости ограничений на возможные действия: полная блокировка; блокировка от записи; предохраняющая блокировка от записи; предохраняющая полная блокировка. Полная блокировка. Означает полное запрещение всяких операций над основными объектами (таблицами, отчетами и экранными формами). Этот вид блокировки обычно применяется при изменении структуры таблицы. Блокировка от записи. Накладывается в случаях, когда можно использовать таблицу, но без изменения ее структуры или содержимого. Такая блокировка применяется, например, при выполнении операции слияния данных из двух таблиц. Предохраняющая блокировка от записи. Предохраняет объект от наложения на него со стороны других операций полной блокировки, либо блокировки от записи. Этот вид блокировки позволяет тому, кто раньше "захватил" объект, успешно завершить модификацию объекта. Предохраняющая блокировка от записи совместима с аналогичной блокировкой (предохраняющей блокировкой от записи), а также с предохраняющей полной блокировкой (см. далее). Примером необходимости использования этой блокировки является режим совместного редактирования таблицы несколькими пользователями. Предохраняющая полная блокировка. Предохраняет объект от наложения на него со стороны других операций только полной блокировки. Обеспечивает максимальный уровень совместного использования объектов. Такая блокировка может использоваться, например, для обеспечения одновременного просмотра несколькими пользователями одной таблицы. В группе пользователей, работающих с одной таблицей, эта блокировка не позволит никому изменить структуру общей таблицы. При незавершенной операции с некоторым объектом и запросе на выполнение новой операции с этим же объектом производится попытка эти операции совместить. Совмещение возможно тогда, когда совместимыми оказываются блокировки, накладываемые конкурирующими операциями. В отношении перечисленных выше четырех блокировок действуют следующие правила совмещения: при наличии полной блокировки над объектом нельзя производить операции, приводящие хотя бы к одному из видов блокировок (полная блокировка несовместима ни с какой другой блокировкой); блокировка от записи совместима с аналогичной блокировкой и предохраняющей полной блокировкой; предохраняющая блокировка от записи совместима с обеими видами предохраняющих блокировок; предохраняющая полная блокировка совместима со всеми блокировками, кроме полной. Обычно в СУБД каждой из выполняемых с БД операций соответствует определенный вид блокировки, которую эта операция накладывает на объект. Пользователям современных СУБД, работающим в интерактивном режиме, не нужно помнить все тонкости механизма блокировки, поскольку система достаточно "разумно" осуществляет автоматическое блокирование во всех случаях, когда это требуется. При этом система сама стремится предоставить всем пользователям наиболее свободный доступ к объектам. При необходимости пользователь и программист может воспользоваться командными или языковыми средствами явного определения блокировок. Например, в СУБД Paradox для явного блокирования отдельной записи во время редактирования таблицы используется команда Record | Lock. Тупики Если не управлять доступом к совместно используемым объектам, то между потребителями ресурсов могут возникать тупиковые ситуации (клинчи, "смертельные объятия" или блокировки). Следует отличать понятие блокировки в смысле контроля доступа к объектам (мы придерживаемся такого термина) от блокировки в смысле тупикового события. Существует два основных вида тупиков: взаимные (deadlock); односторонние (livelock). Простейшим случаем взаимного тупика является ситуация, когда каждый из двух пользователей стремится захватить данные, уже захваченные другим пользователем (рис. 4.8а). В этой ситуации пользователь-1 ждет освобождения ресурса N, в то время как пользователь-2 ожидает освобождения от захвата ресурса М. Следовательно, никто из них не может продолжить работу. В действительности могут возникать и более сложные ситуации, когда выполняются обращения трех и более пользователей к нескольким ресурсам. Односторонний тупик возникает в случае требования получить монопольный доступ к некоторому ресурсу как только он станет доступным и невозможности удовлетворить это требование. Системы управления распределенными БД, очевидно, должны иметь соответствующие средства обнаружения или предотвращения конфликтов, а также разрешения возникающих конфликтов. Одной из наиболее сложных является задача устранения конфликтов в неоднородных системах в случае, если некоторая программа не обрабатывает или обрабатывает некорректно сигналы (уведомления) о наличии конфликтов. При этом важно не только сохранить целостность и достоверность данных в распределенных БД, но и восстановить вычислительный процесс, иногда парализующий пользователей и программы ожиданием чего-то. Пользователи и разработчики приложений в распределенной среде должны предусматривать обработку сигналов о тупиках. 4.4. Информационные системы в локальных сетях Локальная вычислительная сеть дает пользователю прежде всего возможность более эффективной организации групповых работ и совместного использования аппаратных ресурсов: принтеров, факсов, модемов, сканеров, дисков и т. д., а также программно-информационных ресурсов, в том числе баз данных. Рассмотрим основные схемы организации работы с данными в ЛВС. Спектр возможных схем построения информационной системы в ЛВС существенно зависит от возможностей используемых СОС. Основным сервисом современных ЛВС, независимо от типа управления в них (централизованные или одноранговые), является предоставление доступа одного компьютера (компьютера-клиента) к дискам, каталогам (папкам) и файлам другого компьютера (компьютера-сервера). Так, при обращении к внешнему файлу СОС сначала передает по сети файл (часть файла) в оперативную память компьютера, а по завершении работы с ним при необходимости возвращает обновленную версию. Кроме того, полезной функцией является возможность запуска на компьютере программ, хранящихся на другом компьютере. Эти возможности примерно в равной мере предоставляются сетевыми ОС такими, как Novell NetWare З.х (4.х), Windows NT и Windows 95/98. Более слабые сетевые пакеты и утилиты могут предоставлять доступ к информации без автоматического запуска программ. В этом случае пользователь должен сначала скопировать программы и файлы с другого компьютера на свой, после чего запустить программу. Как и на отдельном компьютере, в ЛВС пользователь может управлять БД с помощью средств некоторой СУБД или работая с приложением. В общем случае приложение может выполняться под управлением СУБД или ее ядра, либо быть независимым и выполняться как автономная программа. Для удобства в дальнейшем под СУБД будем понимать любой из этих вариантов. В локальной сети персональных ЭВМ выделяют следующие три варианта создания информационной системы: типа файл-сервер; типа клиент-сервер; основанные на технологии intranet. Информационные системы типа файл-сервер можно строить двумя способами: с использованием несетевых СУБД, предназначенных для применения на отдельной машине; с использованием сетевых СУБД, разрабатываемых для применения в ЛВС. Под сетевой СУБД здесь понимается система с произвольной моделью данных (не обязательно сетевой), ориентированная на использование в сети. Программы несетевой СУБД и используемые ею данные могут храниться на компьютере-сервере (КС) и на компьютере-клиенте (КК). Запуск и функционирование несетевой СУБД, хранящейся на КК и работающей с локальными данными не отличается от обычного режима работы на отдельной ПЭВМ. Если используемые данные хранятся на КС, файловая система сетевой ОС "незаметно" для СУБД выполняет подгрузку нужного файла с удаленного компьютера. Заметим, что не каждая несетевая СУБД без проблем работает в среде любой сетевой ОС. Если несетевая СУБД используется несколькими пользователями сети, то ее программы, а также БД или ее часть в целях экономии дисковой памяти эффективнее хранить на КС. Хранимую на КС БД будем называть центральной БД (ЦБД), а хранимую на КК БД - локальной БД (ЛБД). При запуске СУБД в таком варианте на каждый КК обычно пересылается полная копия основной программы СУБД и один или несколько файлов ЦБД (рис. 4.9). После завершения работы файлы ЦБД должны пересылаться с КК обратно на КС для согласования данных. Существенным недостатком такого варианта применения несетевых СУБД является возможность нарушения целостности данных при одновременной работе с одной БД нескольких пользователей. Поскольку каждая копия СУБД функционирует "не зная" о работе других копий СУБД, то никаких мер по исключению возможных конфликтов не принимается. При этом элементарные операции чтения-записи одних и тех же файлов, как правило, контролирует сетевая ОС. В качестве примеров несетевых СУБД можно назвать первые версии системы dBase III Plus, dBase IY и FoxBase. Сетевые СУБД не имеют указанного недостатка, так как в них предусматривается "контроль соперничества" (concurrency control). Средства контроля позволяют осуществлять координацию доступа к данным, например, введением блокировок к файлам, записям и даже отдельным полям записей. В сетевых СУБД с коллективным использованием файлов БД по-прежнему вся обработка информации производится на КК, а функции КС сводятся к предоставлению большой дисковой памяти. Такой подход нельзя считать эффективным, так как для обеспечения приемлемой скорости процесса обработки информации КК должен обладать высоким быстродействием и иметь большую емкость оперативной памяти., Кроме того, пересылка копий файлов БД и команд управления блокировками по линиям связи существенно увеличивает нагрузку на подсистему передачи данных, что снижает общую производительность сети. Примерами сетевых СУБД являются: FoxPro 2.5 для Windows, dBase IY, Paradox. 3.5 для DOS. Информационные системы типа клиент-сервер отличаются от систем типа файлсервер прежде всего тем, что программы СУБД функционально разделены на две части, называемые сервером и клиентом. Между клиентской и серверной частями системы возможны различные варианты распределения функций (подраздел 4.2). Клиент, или фронтальная программа, отвечает за интерфейс с пользователем, для чего преобразует его запросы в команды запросов к серверной части, а при получении результатов выполняет обратное преобразование и отображение информации для пользователя. В роли клиента выступает пользовательская (разрабатываемая для решения конкретной прикладной задачи программа) или готовая программа, имеющая интерфейс с серверной программой. В качестве готовых клиентских программ могут использоваться текстовые процессоры, табличные процессоры и даже СУБД (например, Access, FoxPro и Paradox). Сервер является основной программой, выполняющей функции управления и защиты данных в базе. В случаях, когда вызов функций сервера выполняется на языке SQL, а именно так часто и происходит, его называют SQL-сервером. В качестве сервера может использоваться ядро профессиональной реляционной СУБД (например, Informix 7.x и Sybase System 10) или некоторый SQL-сервер (например, Novell NetWare SQL и Microsoft SQL Server). Основная часть обработки информации по формированию запросов, составлению отчетов, представлению данных в удобной для пользователя виде и т. д. выполняется на КК. Полные копии файлов БД из КС на КК и обратно (как в случае систем на базе сетевых СУБД) не пересылаются, поскольку для организации полноценного взаимодействия, как правило, достаточно иметь на КК необходимые в данный момент времени записи БД. Все это существенно снижает траффик в сети, ослабляет требования по ресурсам к КК, позволяет создавать более эффективные и надежные информационные системы. В последнее время на компьютере-сервере, кроме собственно данных, хранят Программы обработки данных и запросы. Это обеспечивает увеличение скорости обработки данных (программа обработки либо запрос находится "рядом" с данными), а также эффективность хранения и администрирования программ и запросов общего пользования в одном месте (на компьютере-сервере). Хранимые на компьютере-сервере программы (процедуры) обработки данных называют хранимыми процедурами. Разновидностью хранимой процедуры является так называемый триггер. Триггер (триггерная процедура) автоматически вызывается при возникновении определенных событий в БД. В качестве событий могут быть следующие: операции вставки, обновления и удаления отдельных записей, колонок и полей записей и другие. Примером триггера является программа, запускающая процесс посылки сообщения по электронной почте при достижении размера БД (количества записей) предельного значения. В БД сервера некоторых систем можно хранить и сами запросы, называемые хранимыми командами. Совокупность хранимых команд - это поименованная совокупность команд, получаемых в результате компиляции SQL-запроса. Хранимые команды выполняются значительно быстрее, чем соответствующий SQL-запрос Основная причина ускорения состоит в том, что при выполнении хранимых команд не требуется синтаксический разбор запросов. Дополнительное ускорение выполнения запросов может быть получено в тех случаях, когда сервер БД не просто сохраняет коды команд запросов, а производит оптимизацию сохраняемого кода. Программы сервера (основные, хранимые процедуры и триггеры) могут быть выполнены как обычные программы (Windows 95/98), либо как специально загружаемые модули сетевой ОС (NLM-модули в сети Novell). Программы клиента в общем случае хранятся на КС или на КК, или в обоих местах. В настоящее время среди программных продуктов существует огромное количество универсальных (в смысле пригодности работы с различными серверами БД) средств разработки систем типа клиент-сервер, к числу которых относятся: Delphi (Borland), Power Builder (Powersoft), ERwin (LogicWorks), Visual Basic (Microsoft), CAVisual Objects (Computer Associates), SQL Windows (Gupta) и другие. Кроме того, существуют средства разработки в рамках определенных СУБД (например, для Oracle 7 Designer/2000). Все подобные средства, как правило, относятся к CASE-системам. При построении информационных систем типа клиент-сервер возникает проблема доступа со стороны СУБД или приложений, разработанных в одной среде, к данным, порожденным другой СУБД. В среде Windows эта проблема решается с помощью стандартного интерфейса ODBC (Open Database Connectivity - совместимость . .открытых баз данных) фирмы Microsoft. Основное его назначение заключается в обеспечении унифицированного доступа к локальным и удаленным базам данных различных производителей. Схема доступа приложений к базам данных с помощью ODBC показана на рис.4.12. Доступ приложения к данным происходит путем вызова на языке SQL стандартных функций интерфейса ODBC. На компьютере-клиенте при этом должна функционировать операционная система MS Windows с интерфейсом ODBC. Рис. 4.12. Схема доступа к БД с помощью ODBC Взаимодействие приложения с данными производится с помощью менеджера (диспетчера) драйверов, который подключает необходимый драйвер в соответствии с форматом данных СУБД. Драйвер СУБД, используя сетевые средства, как правило, коммуникационные модули конкретной СУБД, передает SQL-операторы серверу СУБД. Результаты выполнения запросов на сервере передаются обратно в приложение. Рассмотренные схемы функционирования СУБД и внешних приложений касаются наиболее типичных вариантов их построения. 4.5. Информационные системы в Internet и Intranet Обработка информации в среде Internet существенно отличается от обработки информации в локальной сети и, тем более, на отдельном компьютере. Перечислим наиболее важные из них: 1. Большая протяженность коммуникационных линий, что сказывается на временных характеристиках обмена. Кроме того, большая удаленность лишает смысла загрузку программ с одного компьютера на другой и не позволяет выполнять пересылку больших объемов данных в реальном масштабе времени, как в сетевых СУБД локальных сетей. 2. Взаимодействие распределенных элементов ИС происходит с помощью обмена пакетами или сообщениями. Отдельные программные компоненты И С могут быть одного или различных производителей. В последнем случае особую роль приобретает решение проблемы поддержки стандартов на сетевые протоколы и на язык SQL. 3. Сеть Internet отличает от остальных глобальных сетей то, что по масштабам она больше всех других сетей (объединяет другие сети) и принципы ее организации оказывают существенное влияние на использование в сети баз данных. Перед рассмотрением моделей и механизмов использования БД дадим краткую характеристику Internet. Характеристика Internet Основными видами услуг (сервиса), предоставляемых пользователям при подключении к Internet, являются: электронная почта (E-mail); телеконференции (UseNet); система эмуляции удаленных терминалов (TelNet); поиск и передача двоичных файлов (FTP); поиск и передача текстовых файлов с помощью системы меню (Gopher); поиск и передача документов с помощью гипертекстовых ссылок (WWW или "Всемирная паутина"). Создание и развитие этих способов связано с историей Internet. Каждый из них характеризуется своими возможностями и различием в организации протоколов обмена информацией. Под протоколом, в общем случае, понимается набор инструкций, регламентирующих работу взаимосвязанных систем или объектов в сети. Гипертекстовый документ {гипертекст) представляет собой текст, содержащий ссылки на другие фрагменты текстов произвольных документов, в том числе и этого документа. Гипертекстовый документ подготавливается на стандартизованном языке HTML (HyperText Markup Language - язык разметки гипертекста). Он состоит из страниц (web-страниц), доступ к которым основан на протоколе передачи гипертекста (HyperText Transfer Prococol, HTTP). HTML-документ представляет собой ASCII-файл, доступный для просмотра и редактирования в любом редакторе текстов. В отличие от обычного текстового файла, в нем присутствуют специальные команды - тэги, которые указывают правила форматирования документа. С помощью тэгов описываются различные элементы документа: заголовки, абзацы (параграфы), списки, ссылки, формы и т. д. Простейшим примером гипертекста является книга, оглавление которой содержит ссылки (внутренние) в виде номеров страниц на разделы, подразделы, пункты книги, кроме того, в книге имеются внешние ссылки на другие используемые источники информации. Фрагмент документа может включать в себя информацию в виде обычного текста, графического изображения, звука и движущегося изображения (анимации). Гипертекст с нетекстовыми документами часто называют гипермедиа. Важнейшим свойством гипертекста является наличие в нем ссылок на документы, размещаемые на территориально удаленных компьютерах. Документы могут создаваться и редактироваться различными людьми. Вся совокупность взаимосвязанных документов образует гигантскую "паутину". Эта модель подобна модели окружающего нас бесконечного информационного пространства, когда нет строгой иерархии связей, а есть множество связей без начала и конца. Работа сети Internet основана на использовании протокола TCP/IP (Transmission Control Protocol/Internet Protocol - Протокол управления передачей данных/Протокол Internet), который используется для передачи данных в глобальной сети и во многих локальных сетях. TCP/IP в основном реализует функции транспортного и сетевого уровней модели OSI. Он представляет собой семейство коммуникационных протоколов, которые по назначению можно разделить на следующие группы: транспортные протоколы, служащие для управления передачей данных между двумя компьютерами; протоколы маршрутизации, обрабатывающие адресацию данных и определяющие кратчайшие доступные пути к адресату; протоколы поддержки сетевого адреса, предназначенные для идентификации компьютера по его уникальному номеру или имени; прикладные протоколы, обеспечивающие получение доступа к всевозможным сетевым услугам; шлюзовые протоколы, помогающие передавать по сети сообщения о маршрутизации и информацию о состоянии сети, а также обрабатывать данные для локальных сетей; другие протоколы, не относящиеся к указанным категориям, но обеспечивающие клиенту удобство работы в сети. Доступ пользователей к ресурсам Internet обычно производится с помощью программ-навигаторов, или броузеров (от англ. browser). В настоящее время к числу наиболее популярных программ этого класса относятся следующие: Netscape Navigator/ Communicator (Netscape) и MS Explorer (Microsoft). Хотя эти программы основаны на использовании протокола HTTP, они предоставляют простой доступ к другим сервисам Internet: электронной почте, новостям и т. д. Базы данных в Internet и Intranet Технология intranet по существу представляет собой технологию Internet, перенесенную в среду корпоративных ИС. Архитектура информационных систем в Internet и intranet является результатом эволюционного перехода от первых многопользовательских централизованных вычислительных систем (мэйнфреймов) через системы типа клиент-сервер к распределенным системам с централизованной обработкой и подготовкой информации к непосредственному потреблению. Рассмотрим кратко указанные этапы эволюции. 1. В мэйнфреймах вычислительные ресурсы, хранимые данные и программы обработки информации сконцентрированы в одной ЭВМ. Основным средством доступа был алфавитно-цифровой терминал (дисплей), управляемый ЭВМ. Вся обработка информации и подготовка ее к выдаче выполнялись на центральной ЭВМ. С терминалов, как правило, в машину передавались коды нажатия клавиш или содержимое буфера экрана, а обратно на терминал - пересылались отображаемые экраны с соответствующими кодами управления отображением. Достоинством системы является простота администрирования, защиты информации и модификации системы, к недостаткам можно отнести высокую загрузку процессоров и линий связи (как следствие - невысокую реакцию системы при большом количестве пользователей), низкую надежность (выход из строя ЭВМ приводит к полному отказу всей системы), сложность масштабирования системы и некоторые другие. 2. Исторически следующим решением в области информационных систем была архитектура клиент-сервер. В этих системах место терминала заняла ПЭВМ, а мэйнфрейма - компьютерсервер. Ранее мы рассматривали спектр моделей подобных систем с различным распределением функций между компонентами. Если не брать во внимание модель "распределенного представления" (по сути повторяет модель централизованной многопользовательской системы), то можно заключить, что системы типа клиент-сервер имеют следующие достоинства: высокая живучесть и надежность; легкость масштабирования; качественный пользовательский интерфейс; возможность одновременной работы с несколькими приложениями; высокие характеристики оперативности обработки информации. Основным недостатком клиент-серверных систем является то, что они ориентированы на данные, а не на информацию. Это требует от пользователя знания не только предметной области, а и специфики используемой прикладной программы. Существенным недостатком можно считать также сложность переноса таких систем на другие компьютерные платформы и интеграцию с другими пакетами из-за "закрытое™" используемых протоколов взаимодействия компонентов систем. Еще один недостаток заключается в сложности администрирования системы и ее уязвимости при непредсказуемых или злонамеренных действиях пользователя или компьютерных вирусов. 3. Корпоративные системы Intranet, в отличие от систем клиент-сервер, ориентированы не на данные, а на информацию в ее окончательном и пригодном для использования неквалифицированным пользователем виде. Новые системы объединяют в себе преимущества централизованных многопользовательских систем и систем типа клиент-сервер. Им присущи следующие черты: на сервере порождается информация, пригодная для использования, а не данные (например, в случае СУБД - записи БД); при обмене между клиентской и серверной частями используется протокол открытого стандарта, а не какой-то конкретной фирмы; прикладная система находится на сервере, и поэтому для работы пользователя на компьютере-клиенте достаточно иметь программу-навигатор (могут быть и другие решения, когда часть обработки производится на компьютере-клиенте). В случае, когда источником информации в Internet и intranet являются БД, имеет место взаимодействие компонентов WWW и традиционных СУБД. Различают два следующих варианта функционирования программного обеспечения WWW по доступу к БД: на стороне Web-сервера и на стороне Web-клиента. В модели доступа к БД на стороне сервера обращение к серверу БД обычно производится путем вызова программами Web-сервера внешних по отношению к ним программ в соответствии с соглашениями одного из интерфейсов: CGI (Common Gateway Interface - общий шлюзовый интерфейс), FastCGI или API (Application Program Interface интерфейс прикладного программирования). Внешние программы взаимодействуют с сервером БД на языке SQL, непосредственно обращаясь к конкретному серверу или используя драйвер ODBC. Внешние программы пишутся на обычных языках программирования типа Си, Си++ и Паскаль или специализированных языках типа Peri или РНР. Программы, разработанные в соответствии с интерфейсом CGI, называются CGI-сценариями или CGIскриптами. Для поддержки этого механизма на стороне клиента в языке HTML имеется средство включения в документ форм (тэг

языка HTML) представления запросов к БД. Процедура доступа к БД с использованием интерфейса CGI включает в себя следующие этапы: 1. Запрос Web-клиентом у Web-сервера страницы, содержащей форму обращения к БД, если при просмотре документа пользователем Web-клиент встречает ссылку на такую страницу. 2. Заполнение Web-клиентом содержащейся на полученной странице формы запроса к БД и отправка ее Web-серверу. Правильность заполнения формы можно контролировать с помощью несложной программы, непосредственно находящейся в области HTML-страницы, в которой описана форма (обычно для этого используют языки VBScript HnnJavaScript). 3. Web-сервер, получив эту форму, запускает соответствующую внешнюю CGIпрограмму, передавая ей параметры (адрес и имя этой программы указывается в атрибуте ACTION тэга ). 4. Внешняя программа преобразует описанный в форме запрос к БД в соответствующий текст запроса на языке SQL, с которым обращается к серверу БД. 5. После получения результатов запроса внешняя программа формирует требуемую HTML-страницу, передает ее Web-серверу и завершает свое выполнение. 6. Web-сервер передает сформированную HTML-страницу Web-клиенту. Основными достоинствами применения спецификации CGI для организации доступа к данным базы являются следующие: языковая независимость - сценарий может быть написан практически на любом языке программирования, содержащем средства обработки строк; процессная изолированность - сценарий выполняется на сервере как отдельный процесс, не имеющий доступа к защищенной системной информации сервера; широкая распространенность, так как CGI-стандарт применим на каждом Webсервере; архитектурная независимость - программы, разработанные в соответствии с CGIстандартом, не зависят от архитектуры сервера. К главным недостаткам применения спецификации CGI относятся следующие: необходимость всякий раз устанавливать и разрывать соединение с базой данных, поскольку отсутствуют средства поддержания постоянного соединения Web- сервера и СУБД; ограничения на обработку исходной информации для запросов и результатов выполнения запросов; трудоемкость выполнения программ, связанная с запуском программы как отдельного процесса. Это замедляет обработку запросов к данным и снижает эффективность работы сервера. Для устранения недостатков CGI-спецификации разработана спецификация API. Программы, разработанные по этой спецификации, быстрее и эффективнее выполняются, поскольку организованы в виде динамических библиотек. Наиболее известными являются два интерфейса этого вида: NSAPI (компания Netscape) и ISAPI (компания Microsoft). Достоинством этой технологии является ускорение выполнения программ, так как программа выполняется в рамках основного серверного процесса. Сами программы имеют большую функциональность, чем CGI-сценарии, например, появилась возможность контролировать доступ к файлам сервера. К недостаткам спецификации API относятся следующие: языковая зависимость - программа может быть написана только на языке, поддерживаемом данным API. Чаще всего это языки С и C++ (язык Peri, широко применяемый при написании CGI-скриптов, не применяется); слабая защита сервера от ошибок прикладных программ и от возможности несанкционированного доступа к системным ресурсам, поскольку API-программа выполняется в адресном пространстве основного процесса сервера; программы, как правило, не переносимы на другие программно-аппаратные платформы, поскольку привязаны к интерфейсу и архитектуре сервера. Интерфейс FastCGI сочетает преимущества предыдущих технологий и более близок к интерфейсу CGI. Приложения, написанные в соответствии с ним, запускаются как отдельные изолированные процессы, но являются постоянно активными и не завершаются после обращения к данным как CGI-сценарии. При доступе к БД на стороне клиента основным средством реализации механизмов взаимодействия Web-клиента и сервера БД является язык Java. Кроме того, может использоваться JavaScript, разработанный для расширения возможностей декларативного языка HTML (нет операторов присваивания, сравнения, математических функций и пр.) на основе добавления процедурных средств. Программы на языке JavaScript выполняются на компьютере Web-броузером в режиме интерпретации. Если в HTML-документе, требуется получить данные из БД, то поступают следующим образом. 1. На языке Java пишутся дополнительные программы, называемые апплетами (Java-applets), которые затем компилируются. В результате получаются мобильные (машинно-независимые) программы. Последние могут выполняться в режиме интерпретации или служить исходной информацией для генерации программ, готовых к выполнению на разных аппаратно-программных платформах. 2. В тексте HTML-документа в нужных местах ставятся ссылки на соответствующие апплеты. Сами программы хранятся на сервере. 3. В процессе работы с гипертекстом при обнаружении в тексте ссылки на апплет происходит автоматическая пересылка Java-программы с сервера в среду выполнения броузера и загрузка на выполнение. Последняя в диалоге с пользователем уточняет параметры запроса к БД (средства поддержки графического пользовательского интерфейса в языке Java имеются). 4. Получив управление, Java-апплет осуществляет взаимодействие с сервером БД, в результате чего полученная из базы информация представляется пользователю. Для обращений к серверам БД разработан стандарт JDBC (Java DataBase Connectivity - совместимость баз данных для Java), основанный на концепции ODBC. Стандарт JDBC разработан фирмами Sun/JavaSoft и обеспечивает универсальный доступ к различным базам данных на языке Java. Из двух рассмотренных схем однозначного предпочтения тому или иному варианту отдать нельзя. Все зависит от целей и условий разработки клиент-серверных программ (наиболее существенной оказывается зависимость от ОС, а также от вида Web-сервера). Достоинством модели доступа на стороне сервер является сравнительная простота программ-навигаторов (Web-клиентов) и удобство администрирования системы, так как основная часть программного обеспечения находится на машине Web-сервера. Очевидным недостатком системы является возможное ухудшение характеристик оперативности получения информации при большой нагрузке на Web-сервер и нехватке его мощности. Во второй модели клиентская часть системы оказывается сложнее, чем в первой. Это усложняет навигатор, но в to же время разгружает Web-сервер. В сравнительно недавно выпущенных программных продуктах фирмы Microsoft поддерживаются обе схемы. Па стороне клиента (в среде Internet Explorer) существует возможность использовать динамический HTML, который реализуется на языке VBScript. Доступ к данным на стороне сервера осуществляется с помощью так называемых ASPстраниц (Active Server Pages - активные серверные страницы). ASP-страницы - это сценарии на языке VBScript, хранящиеся и выполняемые на Web-сервере (Internet Information Server). Лекция 10 5. Проектирование баз данных 5.1. Проблемы проектирования Избыточное дублирование данных и аномалии Следует различать простое (неизбыточное) и избыточное дублирование данных. Наличие первого из них допускается в базах данных, а избыточное дублирование данных может приводить к проблемам при обработке данных. Приведем примеры обоих вариантов дублирования. Пример неизбыточного дублирования данных представляет приведенное на рис. 5.1 отношение С_Т с атрибутами Сотрудник и Телефон. Для сотрудников, находящихся в одном помещении, номера телефонов совпадают. Номер телефона 4328 встречается несколько раз, хотя для каждого служащего номер телефона уникален. Поэтому ни один из номеров не является избыточным. Действительно, при удалении одного из номеров телефонов будет утеряна информация о том, по какому номеру можно дозвониться до одного из служащих. С_Т Сотрудник Телефон Иванов 3721 Петров 4328 Сидоров 4328 Егоров 4328 Рис. 5.1. Неизбыточное дублирование Пример избыточного дублирования (избыточности) представляет приведенное на рис. 5.2а отношение С_Т_Н, которое, в отличие от отношения С_Т, дополнено атрибутом Н_комн (номер комнаты сотрудника). Естественно предположить, что все служащие в одной комнате имеют один и тот же телефон. Следовательно, в рассматриваемом отношении имеется избыточное дублирование данных. Так, в связи с тем, что Сидоров и Егоров находятся в той же комнате, что и Петров, их номера можно узнать из кортежа со сведениями о Петрове. С_Т_Н а) Сотрудник Телефон Н_комн С_Т_Н б) Сотрудник Телефон Н_комн Иванов 3721 109 Иванов 3721 109 Петров 4328 111 Петров 4328 111 Сидоров 4328 111 Сидоров --- 111 Егоров 4328 111 Егоров --- 111 Рис. 5.2. Избыточное дублирование На рис. 5.2б приведен пример неудачного отношения С_Т_Н, в котором вместо телефонов Сидорова и Егорова поставлены прочерки (неопределенные значения). Неудачность подобного способа исключения избыточности заключается в следующем. Во-первых, при программировании придется потратить дополнительные усилия на создание механизма поиска информации для прочерков таблицы. Во-вторых, память все равно выделяется под атрибуты с прочерками, хотя дублирование данных и исключено. Втретьих, что особенно важно, при исключении из коллектива Петрова кортеж со сведениями о нем будет исключен из отношения, а значит уничтожена информация о телефоне 111-й комнаты, что недопустимо. Возможный способ выхода из данной ситуации приведен на рис. 5.3. Здесь показаны два отношения С_Н и Н_Т, полученные путем декомпозиции исходного отношения С_Т_Н. Первое из них содержит информацию о номерах комнат, в которых располагаются сотрудники, а второе - информацию о номерах телефонов в каждой из комнат. Теперь, если Петрова и уволят из учреждения и, как следствие этого, удалят всякую информацию о нем из баз данных учреждения, это не приведет к утере информации о номере телефона в 111-й комнате. Т_Н Телефон Н_комн С_Н Сотрудник Н_комн 3721 109 Иванов 109 4328 111 Петров 111 Сидоров 111 Егоров 111 Рис. 5.3. Исключение избыточного дублирования Процедура декомпозиции отношения С_Т_Н на два отношения С_Н и Н_Т является основной процедурой нормализации отношений. Избыточное дублирование данных создает проблемы при обработке кортежей отношения, названные Э. Коддом "аномалиями обновления отношения". Он показал, что для некоторых отношений проблемы возникают при попытке удаления, добавления или редактирования их кортежей. Аномалиями будем называть такую ситуацию в таблицах БД, которая приводит к противоречиям в БД, либо существенно усложняет обработку данных. Выделяют три основные вида аномалий: аномалии модификации (или редактирования), аномалии удаления и аномалии добавления. Аномалии модификации проявляются в том, что изменение значения одного данного может повлечь за собой просмотр всей таблицы и соответствующее изменение некоторых других записей таблицы. Так, например, изменение номера телефона в комнате 111 (рис. 5.2а), что представляет собой один единственный факт, потребует просмотра всей таблицы С_Т_Н и изменения поля Н_комн согласно текущему содержимому таблицы в записях, относящихся к Петрову, Сидорову и Егорову. Аномалии удаления состоят в том, что при удалении какого-либо данного из таблицы может пропасть и другая информация, которая не связана напрямую с удаляемым данным. В той же таблице С_Т_Н удаление записи о сотруднике Иванове (например, по причине увольнения или ухода на заслуженный отдых) приводит к исчезновению информации о номере телефона, установленного в 109-й комнате. Аномалии добавления возникают в случаях, когда информацию в таблицу нельзя поместить до тех пор, пока она неполная, либо вставка новой записи требует дополнительного просмотра таблицы. Примером может служить операция добавления нового сотрудника все в ту же таблицу С_Т_Н. Очевидно, будет противоестественным хранение сведений в этой таблице только о комнате и номере телефона в ней, пока никто из сотрудников не помещен в нее. Более того, если в таблице С_Т_Н поле Служащий является ключевым, то хранение в ней неполных записей с отсутствующей фамилией служащего просто недопустимо из-за неопределенности значения ключевого поля. Вторым примером возникновения аномалии добавления может быть ситуация включения в таблицу нового сотрудника. При добавлении таких записей для исключения противоречий желательно проверить номер телефона и соответствующий номер комнаты хотя бы с одним из сотрудников, сидящих с новым сотрудником в той же комнате. Если же окажется, что у нескольких сотрудников, сидящих в одной комнате, имеются разные телефоны, то вообще не ясно, что делать (то ли в комнате несколько телефонов, то ли какой-то из номеров ошибочный). Формирование исходного отношения Проектирование БД начинается с определения всех объектов, сведения о которых будут включены в базу, и определения их атрибутов. Затем атрибуты сводятся в одну таблицу - исходное отношение. Пример. Формирование исходного отношения. Предположим, что для учебной части факультета создается БД о преподавателях. На первом этапе проектирования БД в результате общения с заказчиком (заведующим учебной частью) должны быть определены содержащиеся в базе сведения о том, как она должна использоваться и какую информацию заказчик хочет получать в процессе ее эксплуатации. В результате устанавливаются атрибуты, которые должны содержаться в отношениях БД, и связи между ними. Перечислим имена выделенных атрибутов и их краткие характеристики: ФИО - фамилия и инициалы преподавателя. Исключаем возможность совпадения фамилии и инициалов у преподавателей. Должн - должность, занимаемая преподавателем. Оклад - оклад преподавателя. Стаж - преподавательский стаж. Д_Стаж - надбавка за стаж. Каф - номер кафедры, на которой числится преподаватель. Предм - название предмета (дисциплины), читаемого преподавателем. Группа - номер группы, в которой преподаватель проводит занятия. ВидЗан - вид занятий, проводимых преподавателем в учебной группе. Одно из требований к отношениям заключается в том, чтобы все атрибуты отношения имели атомарные (простые) значения. В исходном отношении каждый атрибут кортежа также должен быть простым. Пример исходного отношения ПРЕПОДАВАТЕЛЬ приведен на рис. 5.4. ПРЕПОДАВАТЕЛЬ ФИО Должн Иванов И.М. преп Иванов И.М. преп Петров М.И. ст. преп Петров М.И. ст. преп Сидоров Н.Г. преп Сидоров Н.Г. преп Егоров В.В. преп Оклад 500 500 800 800 500 500 500 Стаж 5 5 7 7 10 10 5 ДСтаж 100 100 100 100 150 150 100 Каф 25 25 25 25 25 25 24 Предм СУБД ПЛ/1 СУБД Паскаль ПЛ/1 Паскаль ПЭВМ Группа 256 123 256 256 123 256 244 ВидЗан Практ Практ Лекция Практ Лекция Лекция Лекция Рис. 5.4. Исходное отношение ПРЕПОДАВАТЕЛЬ Указанное отношение имеет следующую схему ПРЕПОДАВАТЕЛЬ(ФИО, Должн, Оклад, Стаж, Д_Стаж, Каф, Предм, Группа, ВидЗан). Исходное отношение ПРЕПОДАВАТЕЛЬ содержит избыточное дублирование данных, которое и является причиной аномалий редактирования. Различают избыточность явную и неявную. Явная избыточность заключается в том, что в отношении ПРЕПОДАВАТЕЛЬ строки с данными о преподавателях, проводящих занятия в нескольких группах, повторяются соответствующее число раз. Например, в отношении ПРЕПОДАВАТЕЛЬ все данные по Иванову повторяются дважды. Поэтому, если Иванов И.М. станет старшим преподавателем, то этот факт должен быть отражен в обеих строках. В противном случае будет иметь место противоречие в данных, что является примером аномалии редактирования, обусловленной явной избыточностью данных в отношении. Неявная избыточность в отношении ПРЕПОДАВАТЕЛЬ проявляется в одинаковых окладах у всех преподавателей и в одинаковых добавках к окладу за одинаковый стаж. Поэтому, если при изменении окладов за должность с 500 на 510 это значение изменят у всех преподавателей, кроме, например, Сидорова, то база станет противоречивой. Это пример аномалии редактирования для варианта с неявной избыточностью. Средством исключения избыточности в отношениях и, как следствие, аномалий является нормализация отношений, рассмотрим ее более подробно. 5.2. Метод нормальных форм Проектирование БД является одним из этапов жизненного цикла информационной системы. Основной задачей, решаемой в процессе проектирования БД, является задача нормализации ее отношений. Рассматриваемый ниже метод нормальных форм является классическим методом проектирования реляционных БД. Этот метод основан на фундаментальном в теории реляционных баз данных понятии зависимости между атрибутами отношений. Зависимости между атрибутами Рассмотрим основные виды зависимостей между атрибутами отношений: функциональные, транзитивные и многозначные. Понятие функциональной зависимости является базовым, так как на его основе формулируются определения всех остальных видов зависимостей. Атрибут В функционально зависит от атрибута А, если каждому значению А соответствует в точности одно значение В. Математически функциональная зависимость В от А обозначается записью А->В. Это означает, что во всех кортежах с одинаковым значением атрибута А атрибут В будет иметь также одно и то же значение. Отметим, что А и В могут быть составными - состоять из двух и более атрибутов. В отношении на рис. 5.4 можно выделить функциональные зависимости между атрибутами ФИО->Каф, ФИО->Должн, Должн->Оклад и другие. Наличие функциональной зависимости в отношении определяется природой вещей, информация о которых представлена кортежами отношения. В отношении на рис. 5.4 ключ является составным и состоит из атрибутов ФИО, Предмет, Группа. Функциональная взаимозависимость. Если существует функциональная зависимость вида А->В и В->А, то между А и В имеется взаимно однозначное соответствие, или функциональная взаимозависимость. Наличие функциональной взаимозависимости между атрибутами А и В обозначим как А<->В или В<->А. Пример. Пусть имеется некоторое отношение, включающее два атрибута, функционально зависящие друг от друга. Это серия и номер паспорта (N) и фамилия, имя и отчество владельца (ФИО). Наличие функциональной зависимости поля ФИО от N означает не только тот факт, что значение поля N однозначно определяет значение поля ФИО, но и то, что одному и тому же значению поля N соответствует только единственное значение поля ФИО. Понятно, что в данном случае действует и обратная ФЗ: каждому значению поля ФИО соответствует только одно значение поля N. В данном примере предполагается, что ситуация наличия полного совпадения фамилий, имен и отчеств двух людей исключена. Если отношение находится в 1НФ, то все неключевые атрибуты функционально зависят от ключа с различной степенью зависимости. Частичной зависимостью (частичной функциональной зависимостью) называется зависимость неключевого атрибута от части составного ключа. В рассматриваемом отношении атрибут Должн находится в функциональной зависимости от атрибута ФИО, являющегося частью ключа. Тем самым атрибут Должн находится в частичной зависимости от ключа отношения. Альтернативным вариантом является полная функциональная зависимость неключевого атрибута от всего составного ключа. В нашем примере атрибут ВидЗан находится в полной функциональной зависимости от составного ключа. Атрибут С зависит от атрибута А транзитивно (существует транзитивная зависимость), если для атрибутов А, В, С выполняются условия А->В и В->С, но обратная зависимость отсутствует. В отношении на рис. 5.4 транзитивной зависимостью связаны атрибуты: ФИО->Должн->Оклад Между атрибутами может иметь место многозначная зависимость. В отношении R атрибут В многозначно зависит от атрибута А, если каждому значению А соответствует множество значений В, не связанных с другими атрибутами из R. Многозначные зависимости могут быть "один ко многим" (1:М), "многие к одному" (М: 1) или "многие ко многим" (М:М), обозначаемые соответственно: А=>В, А<=В и А<=>В. Например, пусть преподаватель ведет несколько предметов, а каждый предмет может вестись несколькими преподавателями, тогда имеет место зависимость ФИО<=>Предмет. Так, из таблицы 7.2, приведенной на рис. 5.4., видно, что преподаватель Иванов И.М. ведет занятия по двум предметам, а дисциплина СУБД - читается двумя преподавателями: Ивановым И.М. и Петровым М.И. Замечание. В общем случае между двумя атрибутами одного отношения могут существовать зависимости: 1:1,1:М,М:1 и М:М. Поскольку зависимость между атрибутами является причиной аномалий, стараются расчленить отношения с зависимостями атрибутов на несколько отношений. В результате образуется совокупность связанных отношений (таблиц) со связями вида 1:1,1:М, М:1 и М:М (подраздел 3.3). Связи между таблицами отражают зависимости между атрибутами различных отношений. Взаимно независимые атрибуты. Два или более атрибута называются взаимно независимыми, если ни один из этих атрибутов не является функционально зависимым от других атрибутов. В случае двух атрибутов отсутствие зависимости атрибута А от атрибута В можно обозначить так: А-.->В. Случай, когда А-.->В и B-i->A, можно обозначить А-.=В. Выявление зависимостей между атрибутами Выявление зависимостей между атрибутами необходимо для выполнения проектирования БД методом нормальных форм, рассматриваемого далее. Основной способ определения наличия функциональных зависимостей - внимательный анализ семантики атрибутов. Для каждого отношения существует, но не всегда, определенное множество функциональных зависимостей между атрибутами. Причем если в некотором отношении существует одна или несколько функциональных зависимостей, можно вывести другие функциональные зависимости, существующие в этом отношении. Пример. Пусть задано отношение R со схемой R(A1, A2, A3) и числовыми значениями, приведенными в следующей таблице: А1 12 17 11 13 15 14 A2 21 21 24 25 23 22 A3 34 34 33 31 35 32 Априори известно, что в R существуют функциональные зависимости: А1-> A2 и А2-> A3. Анализируя это отношение, можно увидеть, что в нем существуют еще зависимости: А1-> A3, А1А2-> A3, А1А2АЗ-> А1А2, А1А2-> А2АЗ и т. п. В то же время в отношении нет других функциональных зависимостей, что во введенных нами обозначениях можно отразить следующим образом: А2-,->А1, АЗ-,->А1 и т. д. Отсутствие зависимости А1 от А2 (А2-.->А1) объясняется тем, что одному и тому же значению атрибута А2 (21) соответствуют разные значения атрибута А1 (12 и 17). Другими словами, имеет место многозначность, а не функциональность. Перечислив все существующие функциональные зависимости в отношении R, получим полное множество функциональных зависимостей, которое обозначим F +. Таким образом, для последнего примера исходное множество F = (А1-> А2, А2-> A3), а полное множество F += (А1-> А2, А2-> A3, А1-> A3, А1А2-> A3, А1А2АЗ-> А1А2, А1А2>А2АЗ,...). Для построения F+ из F необходимо знать ряд правил (или аксиом) вывода одних функциональных зависимостей из других. Существует 8 основных аксиом вывода: рефлексивности пополнения транзитивности расширения продолжения псевдотранзитивности объединения декомпозиции. Перечисленные аксиомы обеспечивают получение всех ФЗ, т. е. их совокупность применительно к процедуре вывода можно считать "функционально полной". Содержание аксиом и соответствующие примеры приведены в Приложении 1. Выявим зависимости между атрибутами отношения ПРЕПОДАВАТЕЛЬ, приведенного на рис. 5.4. При этом учтем следующее условие, которое выполняется в данном отношении: один преподаватель в одной группе может проводить один вид занятий (лекции или практические занятия). В результате анализа отношения получаем зависимости между атрибутами, показанные на рис. 5.5. Рис. 5.5. Зависимости между атрибутами ФИО->Oклад ФИО->Должн ФИО->Стаж ФИО->Д_Стаж ФИО->Каф Стаж->Д_Стаж Должн->0клад Оклад->Должк ФИО.Предм.Группа->ВидЗан К выделению этих ФЗ для рассматриваемого примера приводят следующие соображения. Фамилия, имя и отчество у преподавателей факультета уникальны. Каждому преподавателю однозначно соответствует его стаж, т. е. имеет место функциональная зависимость ФИО->Стаж. Обратное утверждение неверно, так как одинаковый стаж может быть у разных преподавателей. Каждый преподаватель имеет определенную добавку за стаж, т. е. имеет место функциональная зависимость ФИО->Д_Стаж, но обратная функциональная зависимость отсутствует, так как одну и ту же надбавку могут иметь несколько преподавателей. Каждый преподаватель имеет определенную должность (преп., ст.преп., доцент, профессор), но одну и ту же должность могут иметь несколько преподавателей, т. е. имеет место функциональная зависимость ФИО->Должн, а обратная функциональная зависимость отсутствует. Каждый преподаватель является сотрудником одной и только одной кафедры. Поэтому функциональная зависимость ФИО->Каф имеет место. С другой стороны, на каждой кафедре много преподавателей, поэтому обратной функциональной зависимости нет. Каждому преподавателю соответствует конкретный оклад, который одинаков для всех педагогов с одинаковыми должностями, что учитывается зависимостями ФИО->Oклад и Должн->Oклад. Нет одинаковых окладов для разных должностей, поэтому имеет место функциональная зависимость Оклад->Должн. Один и тот же преподаватель в одной группе по разным предметам может проводить разные виды занятий. Определение вида занятий, которые проводит преподаватель, невозможно без указания предмета и группы, поэтому имеет место функциональная зависимость ФИО, Предм, Группа->ВидЗан. Действительно, Петров М.И. в 256 группе читает лекции и проводит пратические занятия. Но лекции он читает по СУБД, а практику проводит по Паскалю. Нами не были выделены зависимости между атрибутами ФИО, Предм и Группа, поскольку они образуют составной ключ и не учитываются в процессе нормализации исходного отношения. После того, как выделены все функциональные зависимости, следует проверить их согласованность с данными исходного отношения ПРЕПОДАВАТЕЛЬ (рис. 5.4). Например, Должн.=преп и Оклад=500 всегда соответствуют друг другу во всех кортежах, т. е. подтверждается функциональная зависимость Должн<->Oклад. Так же следует верифицировать и остальные функциональные зависимости, не забывая об ограниченности имеющихся в отношении данных. Нормальные формы Процесс проектирования БД с использованием метода нормальных форм является итерационным и заключается в последовательном переводе отношений из первой нормальной формы в нормальные формы более высокого порядка по определенным правилам. Каждая следующая нормальная форма ограничивает определенный тип функциональных зависимостей, устраняет соответствующие аномалии при выполнении операций над отношениями БД и сохраняет свойства предшествующих нормальных форм. Выделяют следующую последовательность нормальных форм: первая нормальная форма (1НФ); вторая нормальная форма (2НФ); третья нормальная форма (3НФ); усиленная третья нормальная форма, или нормальная форма Бойса-Кодда (БКНФ); четвертая нормальная форма (4НФ); пятая нормальная форма (5НФ). Первая нормальная форма. Отношение находится в 1НФ, если все его атрибуты являются простыми (имеют единственное значение). Исходное отношение строится таким образом, чтобы оно было в 1НФ. Перевод отношения в следующую нормальную форму осуществляется методом "декомпозиции без потерь". Такая декомпозиция должна обеспечить то, что запросы (выборка данных по условию) к исходному отношению и к отношениям, получаемым в результате декомпозиции, дадут одинаковый результат. Основной операцией метода является операция проекции. Поясним ее на примере. Предположим, что в отношении R(A,B,C,D,E,...) устранение функциональной зависимости C->D позволит перевести его в следующую нормальную форму Для решения этой задачи выполним декомпозицию отношения R на два новых отношения R1(A,B,C,E,...) и R2(C,D). Отношение R2 является проекцией отношения R на атрибуты С и D. Исходное отношение ПРЕПОДАВАТЕЛЬ, используемое для иллюстрации метода, имеет составной ключ ФИО. Предм, Группа и находится в 1 НФ, поскольку все его атрибуты простые. В этом отношении в соответствии с рис. 5.5 можно выделить частичную зависимость атрибутов Стаж, Д_Стаж, Каф, Должн, Оклад от ключа - указанные атрибуты находятся в функциональной зависимости от атрибута ФИО, являющегося частью составного ключа. Эта частичная зависимость от ключа приводит к следующему: 1. В отношении присутствует явное и неявное избыточное дублирование данных, например: повторение сведений о стаже, должности и окладе преподавателей, проводящих занятия в нескольких группах и/или по разным предметам; повторение сведений об окладах для одной и той же должности или о надбавках за одинаковый стаж. 2. Следствием избыточного дублирования данных является проблема их редактирования. Например, изменение должности у преподавателя Иванова И.М. потребует просмотра всех кортежей отношения и внесения изменений в те из них, которые содержат сведения о данном преподавателе. Часть избыточности устраняется при переводе отношения в 2НФ. Вторая нормальная форма. Отношение находится в 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально полно зависит от первичного ключа (составного). Для устранения частичной зависимости и перевода отношения в 2НФ необходимо, используя операцию проекции, разложить его на несколько отношений следующим образом: построить проекцию без атрибутов, находящихся в частичной функциональной зависимости от первичного ключа; построить проекции на части составного первичного ключа и атрибуты, зависящие от этих частей. В результате получим два отношения R1 и R2 в 2НФ (рис. 5.6). В отношении R1 первичный ключ является составным и состоит из атрибутов ФИО, Предм, Группа. Напомним, что данный ключ в отношении R1 получен в предположении, что каждый преподаватель в одной группе по одному предмету может либо читать лекции, либо проводить практические занятия. В отношении R2 ключ ФИО. Исследование отношений R1 и R2 показывает, что переход к 2НФ позволил исключить явную избыточность данных в таблице R2 - повторение строк со сведениями о преподавателях. В R2 по-прежнему имеет место неявное дублирование данных. Для дальнейшего совершенствования отношения необходимо преобразовать его в 3НФ. Третья нормальная форма. Определение 1. Отношение находится в 3НФ, если оно находится в 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Существует и альтернативное определение. Определение 2. Отношение находится в 3НФ в том и только в том случае, если все неключевые атрибуты отношения взаимно независимы и полностью зависят от первичного ключа. Доказать справедливость этого утверждения несложно. Действительно, то, что неключевые атрибуты полностью зависят от первичного ключа, означает, что данное отношение находится в форме 2НФ. Взаимная независимость атрибутов (определение приведено выше) означает отсутствие всякой зависимости между атрибутами отношения, в том числе и транзитивной зависимости между ними. Таким образом, второе определение 3НФ сводится к первому определению. Если в отношении R1 транзитивные зависимости отсутствуют, то в отношении R2 они есть: ФИО->Должн->Оклад, ФИО->Оклад->Должн, ФИО->Стаж->Д_Стаж Транзитивные зависимости также порождают избыточное дублирование информации в отношении. Устраним их. Для этого используя операцию проекции на атрибуты, являющиеся причиной транзитивных зависимостей, преобразуем отношение R2, получив при этом отношения R3, R4 и R5, каждое из которых находится в 3НФ (рис. 5.7а). Графически эти отношения представлены на рис. 5.7б. Заметим, что отношение R2 можно преобразовать по-другому, а именно: в отношении R3 вместо атрибута Должн взять атрибут Оклад. На практике построение 3НФ схем отношений в большинстве случаев является достаточным и приведением к ним процесс проектирования реляционной БД заканчивается. Действительно, приведение отношений к 3НФ в нашем примере, привело к устранению избыточного дублирования. Если в отношении имеется зависимость атрибутов составного ключа от неключевых атрибутов, то необходимо перейти к усиленной 3НФ. Усиленная 3НФ или нормальная форма Бойса-Кодда (БКНФ). Отношение находится в БКНФ, если оно находится в 3НФ и в нем отсутствуют зависимости ключей (атрибутов составного ключа) от неключевых атрибутов. У нас подобной зависимости нет, поэтому процесс проектирования на этом заканчивается. Результатом проектирования является БД, состоящая из следующих таблиц: Rl, R3, R4, R5. В полученной БД имеет место необходимое дублирование данных, но отсутствует избыточное. Четвертая нормальная форма. Рассмотрим пример нового отношения ПРОЕКТЫ, схема которого выглядит следующим образом: ПРОЕКТЫ (Номер_проекта, Код_сотрудника, Задание_сотрудника). Первичным ключом отношения является вся совокупность атрибутов: Номер_проекта, Код_сотрудника и Задание_сотрудника. В отношении содержатся номера проектов, для каждого проекта - список кодов сотрудников-исполнителей, а также список заданий, предусмотренных каждым проектом. Сотрудники могут участвовать в нескольких проектах, и разные проекты могут содержать одинаковые задания. Предполагается, что каждый сотрудник, участвующий в некотором проекте, выполняет все задания по этому проекту (предположение не всегда справедливо, но желательно для нашего примера). При такой постановке вопроса единственным возможным ключом отношения является составной атрибут Номер_проекта, Код_сотрудника, Задание_сотрудника. Он, естественно, и стал первичным ключом отношения. Отсюда следует, что отношение ПРОЕКТЫ, находится в форме БКНФ. Пусть исходная информация в этом отношении выглядит следующим образом: Главный недостаток отношения ПРОЕКТЫ состоит в том, что при подключении/отстранении от проекта некоторого сотрудника приходится добавлять/исключать из отношения столько кортежей, сколько заданий имеется в проекте. Внесение или исключение в отношении одного факта о некотором сотруднике требует серии элементарных операций из-за дублирования значений в кортежах. Отсюда возникают вопросы: зачем хранить в кортежах повторяющиеся значения кодов сотрудников? Нужно ли перечислять все задания по каждому проекту, да еще для каждого сотрудника-исполнителя этого проекта? Нельзя ли информацию о привязке заданий к проектам поместить в отдельную таблицу и исключить повторения в основной таблице? Заметим, что косвенный признак аномалии, как и ранее, - дублирование информации в таблице. Выскажем предположение, что причиной аномалии является наличие некоторой зависимости между атрибутами отношения (как увидим далее - многозначной зависимости). Действительно, в отношении ПРОЕКТЫ существуют следующие две многозначные зависимости: Номер_проекта=> Код_сотрудника Номер_проекта=> 3адание_сотрудника В произвольном отношении R(A,В,С) может одновременно существовать многозначная зависимость А=>В и А=>С. Это обстоятельство обозначим как А=>В |С. Дальнейшая нормализация отношений, схожих с отношением Проекты, основывается на следующей теореме. Теорема Фейджина (Fagin R.). Отношение R(A,В,С) можно спроецировать без потерь в отношения R1(A,В) и R2(A,С) в том и только том случае, когда существует зависимость А=>В |С. Под проецированием без потерь здесь понимается такой способ декомпозиции отношения, при котором исходное отношение полностью и без избыточности восстанавливается путем естественного соединения полученных отношений. Поясним проецирование без потерь на примере. Пусть имеется простейшее отношение R(A,В,С), имеющее вид: Построим проекции R1 и R2 на атрибуты А, В и А, С соответственно. Они будут выглядеть так: Результатом операции соединения бинарных отношений R1(A,В) и R2(A,С) по атрибуту А является тернарное отношение с атрибутами А, В и С, кортежи которого получаются путем связывания отношений R1 и R2 по типу 1:М на основе совпадения значений атрибута А. Так, связывание кортежей (к,15) и {(к,1), (к,2)} дает кортежи {(к,15,1), (к,15,2)}. Нетрудно видеть, что связывание R1(A,В) и R2(A,С) в точности порождает исходное отношение R(A,В,С). В отношении R нет лишних кортежей, нет и потерь. Определение четвертой нормальной формы. Отношение R находится в четвертой нормальной форме (4НФ) в том и только в том случае, когда существует многозначная зависимость А=>В, а все остальные атрибуты R функционально зависят от А. Приведенное выше отношение ПРОЕКТЫ можно представить в виде двух отношений: ПРОЕКТЫ-СОТРУДНИКИ и ПРОЕКТЫ-ЗАДАНИЯ. Эти отношения имеют следующую структуру: ПРОЕКТЫ-СОТРУДНИКИ (Номер_проекта, Код_сотрудника). Первичный ключ отношения: Номер_проекта, Код_сотрудника. ПРОЕКТЫ-ЗАДАНИЯ (Номер_проекта, Задание_сотрудника). Первичный ключ отношения: Номер_проекта, Задание_сотрудника. Содержимое соответствующих таблиц будет теперь таким: Как легко увидеть, оба этих отношения находятся в 4НФ и свободны от замеченных недостатков. Дублирование значений атрибутов кодов сотрудников пропало. Попробуйте самостоятельно соединить эти отношения и убедиться в том, что в точности получится отношение ПРОЕКТЫ. В общем случае не всякое отношение можно восстановить к исходному. В нашем случае восстановление возможно потому, что каждый сотрудник, участвующий в некотором проекте, выполнял все задания по этому проекту (именно это укладывается в принцип 1:М соединения отношений). Сами же сотрудники участвовали в нескольких проектах, и разные проекты могли содержать одинаковые задания. Пятая нормальная форма. Результатом нормализации всех предыдущих схем отношений были два новых отношения. Иногда это сделать не удается, либо получаемые отношения заведомо имеют нежелательные свойства. В этом случае выполняют декомпозицию исходного отношения на отношения, количество которых превышает два. Рассмотрим отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ, которое имеет заголовок СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (Код_сотрудника, Код_отдела, Номер_проекта). Первичный ключ отношения включает все атрибуты: Код_сотруд-ника, Код_отдела и Номер_проекта. Пусть в этом отношении один сотрудник может работать в нескольких отделах, причем в каждом отделе он может принимать участие в нескольких проектах. В одном отделе могут работать несколько сотрудников, но каждый проект выполняет только один сотрудник. Функциональных и многозначных зависимостей между атрибутами не существует. Это отношение является частью базы данных вымышленного научного подразделения НИИЧАВО - Научно-Исследовательского Института ЧАродейства и ВОлшебства из повести А. и Б.Стругацких "Понедельник начинается в субботу". Коды отделов здесь обозначают: АД - Администрация, ВЦ - Вычислительный центр, ЛС -Линейного счастья, РД - Родильный дом, СЖ - Смысла жизни, УП - Универсальных превращений. Исходя из структуры отношения СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ можно заключить, что оно находится в форме 4НФ. Тем не менее в отношении могут быть аномалии, связанные с возможностью повторения значений атрибутов в нескольких кортежах. Например, то что сотрудник может работать в нескольких отделах, при увольнении сотрудника требует отыскания и последующего удаления из исходной таблицы нескольких записей. Введем определение зависимости соединения. Отношение R(X, Y,... , Z) удовлетворяет зависимости соединения, которую обозначим как *(Х, Y,..., Z), в том и только в том случае, если R восстанавливается без потерь путем соединения своих проекций на X, Y,..., Z. Зависимость соединения является обобщением функциональной и многозначной зависимостей. Определение пятой нормальной формы. Отношение R находится в 5НФ (или нормальной форме проекции-соединения - PJ/NF) в том и только том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R. Образуем составные атрибуты отношения СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ: С0={ Код_сотрудиика, Код_отдела} СП=4 Код_сотрудника, Номер_проекта} ОП={ Код_отдела, Номер_проекта}. Покажем, что если отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ спроецировать на составные атрибуты СО, СП и ОП, то соединение этих проекций дает исходное отношение. Это значит, что в нашем отношении существовала зависимость соединения *(СО, СП, ОП). Проекции на составные атрибуты назовем соответственно СОТРУДНИКИ-ОТДЕЛЫ, СОТРУДНИКИ-ПРОЕКТЫ и ОТДЕЛЫ-ПРОЕКТЫ. Ранее мы выполняли соединение двух проекций и сразу получали искомый результат. Для восстановлении отношения из трех (или нескольких) проекций надо получить все попарные соединения (так как информация о том, какое из них "лучше", отсутствует), над которыми затем выполнить операцию пересечения множеств. Проверим, так ли это. СОТРУДНИКИОТДЕЛЫ Код Код сотрудника отдела 01 РД 02 АД 02 АД 03 УП 03 УП 04 АД 04 АД 05 ЛС 05 ЛС 06 УП 06 УП 08 ВЦ 08 ВЦ СОТРУДНИКИ-ПРОЕКТЫ Код Номер сотрудника проекта 01 036 02 004 02 004 02 004 03 004 03 004 03 004 04 019 05 001 05 004 05 004 05 004 06 004 06 007 ОТДЕЛЫ-ПРОЕКТЫ Код Номер отдела проекта РД 036 АД 004 ЛС 004 УП 004 АД 004 ЛС 004 УП 004 АД 019 ЛС 001 АД 004 ЛС 004 УП 004 УП 004 УП 007 09 09 10 ВЦ ВЦ СЖ 08 08 09 09 10 ВЦ ВЦ ВЦ ВЦ СЖ 013 014 013 014 013 013 014 013 014 013 Получим попарные соединения трех приведенных выше отношений, которые будут иметь вид: *(СО,СП) Код сотрудника 01 02 03 04 05 05 06 08 09 10 Код отдела РД АД УП АД ЛС ЛС УП ВЦ ВЦ СЖ Номер проекта 036 004 004 019 001 004 007 013 014 013 Нетрудно увидеть, что пересечение всех отношений дает исходное отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ. *(СО,ОП) Код сотрудника 01 02 02 03 03 04 04 05 05 06 06 08 08 09 09 10 Код отдела РД АД АД УП УП АД АД ЛС ЛС УП УП ВЦ ВЦ ВЦ ВЦ СЖ Номер проекта 036 004 019 004 007 004 019 001 004 004 007 013 014 013 014 013 *(СП, ОП) Код сотрудника 01 02 02 02 03 03 03 04 05 05 05 05 06 06 08 08 09 09 10 Код отдела РД АД ЛС УП АД ЛС УП АД ЛС АД ЛС УП УП УП ВЦ ВЦ ВЦ ВЦ СЖ Номер проекта 036 004 004 004 004 004 004 019 001 004 004 004 004 007 013 014 013 014 013 Замечание. Существуют и другие способы восстановления исходного отношения из его проекций. Так, для восстановления отношения СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ можно соединить отношения СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ по атрибуту Код_сотрудника, после чего полученное отношение соединить с отношением ОТДЕЛЫ-ПРОЕКТЫ по составному атрибуту (Код_отдела, Номер_проекта). Отношения СОТРУДНИКИ-ОТДЕЛЫ, СОТРУДНИКИ-ПРОЕКТЫ и ОТДЕЛЫПРОЕКТЫ находятся в 5НФ. Эта форма является последней из известных. Условия ее получения довольно нетривиальны и поэтому она почти не используется на практике. Более того, она имеет определенные недостатки! Прдположим, необходимо узнать, где и какие проекты исполняет сотрудник с кодом 02. Для этого в отношении СОТРУДНИКИ-ОТДЕЛЫ найдем, что сотрудник с кодом 02 работает в отделе АД, а из отношения ОТДЕЛЫ-ПРОЕКТЫ найдем, что в отделе АД выполняются проекты 004 и 019, А это значит, что сотрудник 02 должен выполнять проекты 004 и 019. Увы, информация о том, что сотрудник с кодом 02 выполняет проект 019, ошибочна (см. исходное отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ). Такие противоречия можно устранить только путем совместного рассмотрения всех проекций основного отношения. Именно поэтому после соединения проекций и выполнялась операция их пересечения. Безусловно, это -'недостаток. Отметим, что наличие недостатков не требует обязательного отказа от определенных видов нормальных форм. Надо учитывать недостатки и условия их проявления. В некоторых постановках задач недостатки не проявляются. На практике обычно ограничиваются структурой БД, соответствующей 3НФ или БКНФ. Поэтому процесс нормализации отношений методом нормальных форм предполагает последовательное удаление из исходного отношения следующих межатрибутных зависимостей: частичных зависимостей неключевых атрибутов от ключа (удовлетворение требований 2НФ); транзитивных зависимостей неключевых атрибутов от ключа (удовлетворение требований 3НФ); зависимости ключей (атрибутов составных ключей) от неключевых атрибутов (удовлетворение требований БКНФ). Кроме метода нормальных форм Кодда, используемого для проектирования небольших БД, применяют и другие методы, например, метод ER-диаграмм (метод "Сущностьсвязь"). Этот метод используется при проектировании больших БД, на нем основан ряд средств проектирования БД. Метод ER-диаграмм рассматривается в следующем разделе. На последнем этапе метода ER-диаграмм отношения, полученные в результате проектирования, проверяются на принадлежность их к БКНФ. Этот этап может выполняться уже с использованием метода нормальных форм. После завершения проектирования создается БД с помощью СУБД.