Анализ особенностей распределенных баз данных

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

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

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

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

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

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

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

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

Цель исследования состоит в исследовании и анализе распределенных баз данных и распределенных СУБД.

Соответственно задачами исследования являются:

1. Определить понятия базы данных;

2. Рассмотреть свойства баз данных;

3. Рассмотреть понятие распределенных баз данных и системы баз данных;

4. Рассмотреть подробно технологию «клиент-сервер».

1. Теоретическое описание баз данных

1.1 Определение и характеристики распределенных систем баз данных

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

Под распределенной базой данных (Distributed DataBase - DDB) подразумевается база данных, которая включает в себя фрагменты из нескольких баз данных, располагающихся на различных узлах сети компьютеров и могут управляться различными СУБД. Распределенная база данных выглядит с точки зрения пользователей и прикладных программ как обычная локальная база данных. В этом смысле слово «распределенная» отражает способ организации базы данных, но не внешнюю ее характеристику («распределенность» базы данных невидима извне).

К. Дейтом были сформулированы 12 свойств типичной распределенной базы данных:

1. Локальная автономия (local autonomy) - управление данными на каждом из узлов распределенной системы выполняется локально. База данных, расположенная на одном из узлов, является неотъемлемым компонентом распределенной системы. Будучи фрагментом общего пространства данных, она, в то же время функционирует как полноценная локальная база данных; управление ею выполняется локально и независимо от других узлов системы.

2. Независимость узлов (no reliance on central site) - все узлы равноправны и независимы, а расположенные на них базы являются равноправными поставщиками данных в общее пространство данных. База данных на каждом из узлов самодостаточна - она включает полный собственный словарь данных и полностью защищена от несанкционированного доступа.

3. Непрерывные операции (continuous operation) - возможность непрерывного доступа к данным (известное «24 часа в сутки, семь дней в неделю») в рамках базы данных вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах. Это качество можно выразить лозунгом «данные доступны всегда, а операции над ними выполняются непрерывно».

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

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

6. Прозрачное тиражирование (replication independence) - возможность переноса изменений между базами данных средствами, невидимыми пользователю распределенной системы. Данное свойство означает, что тиражирование возможно и достигается внутрисистемными средствами.

7. Обработка распределенных запросов (distributed query processing) - возможны несколько способов пересылки данных, позволяющих выполнить рассматриваемый запрос.

8. Обработка распределенных транзакций (distributed transaction processing) - возможность выполнения операций обновления распределенной базы данных (INSERT, UPDATE, DELETE), которые не разрушают целостность и согласованность данных. Эта цель достигается применением двухфазного протокола фиксации транзакций (two-phase commit protocol), ставшего фактическим стандартом обработки распределенных транзакций. Его применение гарантирует согласованное изменение данных на нескольких узлах в рамках распределенной (или, как ее еще называют, глобальной) транзакции.

9. Независимость от оборудования (hardware independence) - в качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей.

10. Независимость от операционных систем (operationg system independence) - многообразие операционных систем, управляющих узлами распределенной системы.

11. Прозрачность сети (network independence) - доступ к любым базам данных может осуществляться по сети. Спектр поддерживаемых конкретной СУБД сетевых протоколов не должен быть ограничением системы с распределенными базами данных. Данное качество формулируется максимально широко - в распределенной системе возможны любые сетевые протоколы.

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

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

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

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

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

1) набор логически связанных разделяемых данных;

2) сохраняемые данные разбиты на некоторое количество фрагментов;

3) между фрагментами может быть организована репликация данных;

4) фрагменты и их реплики распределены по различным узлам;

5) узлы связаны между собой сетевыми соединениями;

6) работа с данными на каждом узле управляется локальной СУБД.

СУБД на каждом узле способна поддерживать автономную работу локальных приложений.

1.2 Однородные и неоднородные базы данных

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

Однородные распределенные системы баз данных имеют в своей основе один продукт СУБД, обычно с единственным языком баз данных (например, SQL с расширениями для управления распределенными данными). СУБД с поддержкой однородного распределения являются сильно связанными системами, их встроенные средства поиска данных и средства обработки запросов оптимизированы и настроены для достижения максимальной производительности и пропускной способности. На рис. 2.1 изображена структура типичной однородной среды распределенной базы данных.

Рисунок 1.1 - Архитектура однородной распределенной базы данных

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

Противоположностью однородных систем распределенных БД являются неоднородные распределенные системы БД. Неоднородные системы включают два или более существенно различающихся продукта управления данными (например, реляционные СУБД от разных поставщиков, таких, как Oracle и Digital Equipment Corp., или СУБД одного поставщика, но функционирующие на разных платформах и использующие различные структуры баз данных, такие, как DB2 и SQL/DS компании IBM). На рис. 1.2 показана типичная конфигурация неоднородной распределенной базы данных.

Рисунок 1.2 - Простая конфигурация неоднородной распределенной базы данных

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

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

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

Однако при проектировании РБД методом «сверху вниз» предполагается, что ее объекты не будут сосредоточены в одном месте, а распределятся по нескольким вычислительным системам (рисунок 1.3).

Рисунок 1.3 - Построение распределенной базы данных методом «сверху-вниз»

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

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

2. Распределение баз данных

2.1 Архитектура распределения СУБД

В сегодняшнем быстро меняющемся компьютерном мире сосуществуют по крайней мере три основные идеологии: клиент-сервер, Web и распределенные объекты (DCOM, CORBA). Внутри каждого направления также существует большое количество решений и стандартов от разных производителей. Сегодняшняя ситуация вызывает очень большую озабоченность независимых разработчиков и потребителей: Какую технологию выбрать и что будет со мной и моим бизнесом, если я приму неправильное решение? При этом очевидно, что цена ошибки будет весьма высока, кроме того большие средства уже вложены в разработку и эксплуатацию уже существующих систем.

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

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

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

Рисунок 2.1 - Сравнение технологий файлового сервера и «клиент-сервера»

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

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

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

Различают двухуровневую и трехуровневую модель «клиент-сервер». На рисунке 2.2 представлена двухуровневая модель «клиент-сервер». Эта модель, возможно, наиболее общая, поскольку она подобна схеме разработки локальных баз данных. Многие системы «клиент-сервер», используемые сегодня, развились из существующих локальных приложений базы данных, которые хранят свои данные в файле на сервере. Перенос систем осуществляется для повышения эффективности работы, защищенности и надежности базы данных.



Рисунок 2.2 - Двухуровневая модель «клиент-сервер»

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

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

2) позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т. п.

Недостатки модели:

1) неработоспособность сервера может сделать неработоспособной всю вычислительную сеть;

2) поддержка работы данной системы требует отдельного специалиста - системного администратора;

3) высокая стоимость оборудования.

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

Трехуровневая архитектура клиент-сервер -- разновидность модели «клиент-сервер», в которой функция обработки данных вынесена на один или несколько отдельных серверов. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов.

Достоинства:

1) масштабируемость;

2) конфигурируемость -- изолированность уровней друг от друга позволяет (при правильном развертывании архитектуры) быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;

3) высокая безопасность;

4) высокая надёжность;

5) низкие требования к скорости канала (сети) между терминалами и сервером приложений;

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

Недостатки вытекают из достоинств. По сравнению c клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трёхуровневой архитектуры:

1) более высокая сложность создания приложений;

2) сложнее в разворачивании и администрировании;

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

4) высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.

На рисунке 2.3 показана трехуровневая модель «клиент-сервер». Здесь клиент это пользовательский интерфейс к данным, а данные находятся на удаленном сервере. Клиентное приложение делает запросы для получения доступа или изменения данных через сервер. Если клиент, сервер и бизнес-правила распределены по отдельным компьютерам, разработчик может оптимизировать доступ к данным и поддерживать их целостность во всей системе.

Рисунок 2.3 - Трехуровневая модель «клиент-сервер»

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

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

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

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

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

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

2.2 Проектирование распределенной БД и стратегии распределения данных

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

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

Для проектирования распределенных баз данных требуется решить следующие задачи:

1) состав хранимых данных;

2) перечень решаемых задач и необходимая для них условно-постоянная информация;

3) сведения о том, какие задачи, каким клиентом с ка- кой частотой используются.

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

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

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

Проектирование баз данных происходит в четыре этапа.

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

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

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

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

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

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

На этапе физического проектирования решаются вопросы, связанные с производительностью системы, определяются структуры хранения данных и методы доступа.

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

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

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

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

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

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

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

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

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

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

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

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

При анализе БД с целью определения схемы размещения по узлам учитывают:

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

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

· частота запуска приложений;

· узел, на котором запускается приложение;

· требования к производительности транзакций и приложений;

· требования к времени реакции системы за запросы и т.д.

Критерии, по которым производится определение и размещение фрагментов БД:

1) локальность ссылок;

2) повышение надежности и доступности (репликация);

3) производительность (наличие «узких» мест или неэффективное использование ресурсов системы);

4) баланс между ёмкостью и стоимостью внешней памяти;

5) минимизация расходов на передачу данных.

Стратегия распределения данных по узлам сети ЭВМ могут классифицироваться в зависимости от количества узлов, содержащих данные, и наличия дублирования информации, а также архитектурой системы и программным обеспечением СУБД. Рассмотрим четыре основные стратегии распределения данных:

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

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

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

К недостаткам метода относится то, что часть удаленных запросов или транзакций могут потребовать доступ ко всем серверам, что увеличивает время ожидания и цену; необходимо иметь сведения о размещении данных в БД. Однако доступность и надежность увеличиваются. Расчлененные базы данных наиболее подходят к случаю совместного использования локальных и глобальных сетей ЭВМ.

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

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

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

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

Заключение

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

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

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

В приведенных планах-конспектах наиболее достаточно раскрывается тема «Информация. Информационные процессы и системы» и в процессе изучения информатики эта тема играет значительную роль. Поэтому следует уделять данной теме огромное внимание. Незнание данной темы приводит к потере смысла изучения дисциплины «Информатика и ИКТ» в дальнейшем.

Литература

локальный сервер распределенный компьютер

1. Арсеньев Б.П., Яковлев С.А. Интеграция распределенных баз данных. - СПб.: Лань, 2001. - 461с.

2. Бураков П.В., Петров В.Ю. Введение в системы баз данных: Учебное пособие. - СПб: СПбГУ ИТМО, 2010. - 128с.

3. Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. - 2-е изд., испр. и доп. - М.: Форум, Инфра-М, 2009. - 400с.

4. Горев А., Макашарипов С., Ахаян Р. Эффективная работа с СУБД. - М.: Финансы и статистика, 2004. - 298с.

5. Дейт К.Дж. Введение в системы баз данных. - 8-е изд., Пер. с англ. -- М.: Вильяме, 2005. - 1328с.

6. Диго С.М. Базы данных: проектирование и использование: учебник для студ. вузов / С.М. Диго. - М.: Финансы и статистика, 2005. 592с.

7. Кагаловский М.Р. Энциклопедия технологий баз данных. - М.: Финансы и статистика, 2002. - 800с.

8. Карпова Т.С. Базы данных: Модели, разработка, реализация: Учебное пособие. - СПб.: Питер, 2002. - 303с.

9. Коннолли Т., Карелин Б. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е изд.:пер. с англ. М.: Вильяме, 2003. - 1440с.

10. Корнеев В.В., Гареев А.Ф., Васютин С.В., Райх В.В. Базы данных. Интеллектуальная обработка информации. - М.:Нолидж, 2000. - 352с.

11. Корнеев И.К., Машурцев В.А. Информационные технологии в управлении. -- М.: ИНФРА-М, 2001. - 158с.

12. Коровин Е.Н. Методология прогнозирования и оптимального управления территориально распределенными социально-экономическими системами на основе трансформации информации и многовариантного моделирования: Дис. ... д-ра техн. наук. Воронеж, 2005. - 356с.

Размещено на Allbest.ru

...