Файл: Учебнопрактическое пособие Владимир 2021.pdf

178
Классификация СУБД:
По типу поддерживаемых моделей данных: СУБД, поддержи- вающие иерархические, сетевые, реляционные и другие модели.
По классу используемых аппаратных платформ: СУБД, ориен- тированные на работу в среде больших машин (mainframe) и СУБД и персональных компьютеров различной архитектуры (IBM PC, Apple
Macintosh, Sun и т.д.).
По типу вычислительных систем: СУБД для автономно исполь- зуемых компьютеров (DBase, FoxBase, Ребус), а также СУБД для ра- боты в глобальных и локальных сетях, так называемые системы управления распределенными базами данных (СУРБД) (MSt Access,
Paradox, MSt SQL Server, Oracle, Informix).
По степени промышленного освоения: стандартные, промыш- ленно эксплуатируемые типовые СУБД, и системы, в основе которых лежат уникальные разработки.
По характеру создаваемых приложений: СУБД, используемые для разработки баз данных средней степени сложности и объема для предприятий малого и среднего бизнеса (MSt Access) и СУБД, пред- назначенные для построения крупных корпоративных баз данных вы- сокой степени сложности (MS SQL Server, которая принципиально позволяет поддерживать несколько сотен баз данных, каждая из кото- рых может удовлетворять информационные потребности десятков и сотен пользователей).
В проектировании баз данных выделяются следующие этапы:

анализ информационных потребностей;

инфологическое моделирование;

логическое проектирование;

физическая реализация.
Анализ информационных потребностей. На этом этапе разра- ботчик базы данных анализирует информацию в исследуемой пред- метной области и определяет, какие задачи будут решаться основны- ми пользователями – должностными лицами – с помощью базы дан- ных. В обязательном порядке на этом этапе определяется, с какими запросами пользователи будут обращаться к базе и какие выходные

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

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

181

легкая масштабируемость сети;

производительность, соизмеримая с производительностью суперкомпьютеров;

небольшая сумма вложенных средств.
Системы распределенных вычислений применяются:

в интернет-проектах, с использованием мощностей персо- нальных компьютеров интернет-пользователей для решения самых разнообразных задач;

на уровне локальных сетей, например при сетевом ренде- ринге. Если требуется отрендерить много больших изображений, то данные рассылаются по сети и рендерингом занимаются сетевые компьютеры, а финальная картинка собирается на сервере.
История развития систем распределенных вычислений
Идея создания систем распределенных вычислений родилась в
1970 году. Первые эксперименты с сетевыми программами вылились в создание первого вируса, распространяющегося по сети под именем
Creeper (“Вьюнок”), и последовавшим за ним его убийцы Reaper
(“Жнец” или “Потрошитель”). Распространяясь по прародителю со- временного Интернета – сети ARPAnet, обе программки эффективно загружали память сетевых машин и отнимали драгоценное процес- сорное время.
В 1973 году детище компании PARC (Xerox Palo Alto Research
Center), являвшееся по своей сути первым “червем”, последовательно и обстоятельно загрузило 100 компьютеров в Ethernet-сети компании таким образом, что все свободное (!) процессорное время было отда- но под деятельность червя: создание и рассылку себе подобных. Та- кая на первый взгляд неполезная вещь, как вирус, дала идею для со- здания систем сетевого рендеринга на базе компьютеров Apple.
Новый прорыв в области систем распределенных вычислений пришелся на период экспансии сети Интернет в начале 90-х. В первом проекте, получившем широкую огласку, были задействованы не- сколько тысяч компьютеров по всей глобальной Сети. Целью проекта

182 был взлом алгоритма шифрования методом прямого перебора. Но вторым и значительно более популярным проектом стал SETI@home.
В дальнейшем возникла идея мета-компьютинга. Термин возник вместе с развитием высокоскоростной сетевой инфраструктуры в начале 90-х годов и относился к объединению нескольких разнород- ных вычислительных ресурсов в локальной сети организации для ре- шения одной задачи. Основная цель построения мета-компьютера в то время заключалась в оптимальном распределении частей работы по вычислительным системам различной архитектуры и различной мощности.
В дальнейшем, исследования в области технологий мета- компьютинга были развиты в сторону однородного доступа к вычис- лительным ресурсам большого числа (вплоть до нескольких тысяч) компьютеров в локальной или глобальной сети. Компонентами мета- компьютера могут быть как простейшие ПК, так и мощные массивно- параллельные системы. Что важно, мета-компьютер может не иметь постоянной конфигурации - отдельные компоненты могут включать- ся в его конфигурацию или отключаться от нее; при этом технологии мета-компьютинга обеспечивают непрерывное функционирование системы в целом.
Наилучшим образом для решения на мета-компьютерах подхо- дят задачи переборного и поискового типа, где вычислительные узлы практически не взаимодействуют друг с другом и основную часть ра- боты производят в автономном режиме. Основная схема работы в этом случае примерно такая: специальный агент, расположенный на вычислительном узле (компьютере пользователя), определяет факт простоя этого компьютера, соединяется с управляющим узлом мета- компьютера и получает от него очередную порцию работы (область в пространстве перебора). По окончании счета по данной порции вы- числительный узел передает обратно отчет о фактически проделан- ном переборе или сигнал о достижении цели поиска.
Основные исследовательские проекты в области мета- компьютинга:
1) "Distributed.net". http://www.distributed.net/.

183
Одно из самых больших объединений пользователей Интернет, предоставляющих свои компьютеры для решения крупных перебор- ных задач. Основные проекты связаны с задачами взлома шифров
(RSA Challenges). В частности, 19 января 1999 года была решена предложенная RSA Data Security задача расшифровки фразы, закоди- рованной с помощью шифра DES-III. В настоящее время в distributed.net идет работа по расшифровке фразы, закодированной с
64-битным ключом (RC5-64). С момента начала проекта в нем зареги- стрировались 191 тыс. человек. Достигнута скорость перебора, равная
75 млрд. ключей в секунду (всего требуется проверить 264 ключей).
За решение этой задачи RSA предлагает приз в $10 тыс.
2)
GIMPS
– Great Internet Mersenne Prime Search. http://www.mersenne.org/ .
Поиск простых чисел Мерсенна (т.е. простых чисел вида 2P-1).
С начала проекта было найдено 4 таких простых числа. Организация
Electronic Frontier Foundation предлагает приз в $100 тыс. за нахожде- ние простого числа Мерсенна с числом цифр 10 миллионов.
3) Проект SETI@home (Search for Extraterrestrial Intelligence) – поиск внеземных цивилизаций с помощью распределенной обработки данных, поступающих с радиотелескопа. Присоединиться может лю- бой желающий. Доступны клиентские программы для Windows, Mac,
UNIX, OS/2 (клиент Windows срабатывает в качестве screen-saver'а).
Для участия в проекте зарегистрировались около 920 тыс. человек.
4) Globus. http://www.globus.org.
Разработка ПО для организации распределенных вычислений в
Интернет. Проект реализуется в Argonne National Lab. Цель The
Globus Project – построение т.н. "computational grids", включающих в себя вычислительные системы, системы визуализации, эксперимен- тальные установки. В рамках проекта проводятся исследовании по построению распределенных алгоритмов, обеспечению безопасности и отказоустойчивости мета-компьютеров.
5) Condor. http://www.cs.wisc.edu/condor/ .
Система Condor разрабатывается в университете шт. Висконсин
(Madison). Condor распределяет независимые подзадачи по суще-

184 ствующей в организации сети рабочих станций, заставляя компьюте- ры работать в свободное время (то есть в то время, когда они проста- ивали бы без своих пользователей). Программное обеспечение систе- мы Condor доступно бесплатно. В настоящее время поддерживаются платформы SGI, Solaris, Linux, HP-UX, и Digital Unix, однако плани- руется также поддержка Windows NT.
3.3. Особенности распределенных баз данных и СУБД
Под распределенной базой данных(РБД) обычно подразумевают базу данных, включающую фрагменты из нескольких баз данных, ко- торые располагаются на различных узлах сети компьютеров, и, воз- можно управляются различными СУБД.
С точки зрения пользователей и прикладных программ распре- деленная база данных выглядит как обычная локальная БД, ее «рас- пределенность» не заметна извне, она отражает лишь способ органи- зации БД.
Кристофер Дейт, специалист в области реляционных баз дан- ных, выявил двенадцать основных свойств распределенных БД:
• Локальная автономия (local autonomy);
• Независимость узлов (no reliance on central site);
• Непрерывные операции (continuous operation);
• Прозрачность расположения (location independence);
• Прозрачная фрагментация (fragmentation independence);
• Прозрачное тиражирование (replication independence);
• Обработка распределенных запросов (distributed query
processing);
• Обработка распределенных транзакций (distributed transaction
processing);
• Независимость от оборудования (hardware independence);
• Независимость от операционных систем (operationg system
independence);
• Прозрачность сети (network independence);
• Независимость от баз данных (database independence).

185
Локальная автономия. Согласно определению Дейта, это свой- ство РБД означает, что, несмотря на общую распределенность БД, управление данными на каждом из узлов выполняется локально. БД, расположенная на одном из элементов системы(узле), в то же время является важным составным элементом распределенной системы
(РС). Однако локальная БД может полностью самостоятельно функ- ционировать и работать с данными внутри локального узла системы.
Независимость от центрального узла. Если рассматривать иде- альную распределенную БД, то все узлы в такой системе должны яв- ляться независимыми от центрального узла, а каждая локальная БД является равноправным поставщиком данных в общую систему. При этом все БД в данной системе являются «самодостаточными».
Непрерывные операции. Это свойство распределенных баз дан- ных заключается в возможности доступа к данным системы в любое время (24 часа в сутки в любой день в году). В идеале предполагают, что доступ к данным осуществляется постоянно, а операции над ними производятся непрерывно.
Прозрачность расположения. Несмотря на название (прозрач- ность расположения) это свойство распределенной БД означает, что пользователь не должен ничего знать о физическом месте хранения данных и их расположения в узлах системы. Все запросы к данным осуществляются через прикладные программы по физическим кана- лам связи незаметно для конечного пользователя.
Прозрачная фрагментация. Согласно этому свойству, в системе должна быть возможность распределенного размещения данных на разных узлах. Выделяют несколько видов фрагментации: горизон- тальная и вертикальная. При горизонтальной фрагментации строки одной логической таблицы могут храниться в идентичных таблицах на различных узлах РБД. При вертикальной фрагментации по узлам системы ведется распределение столбцов одной логической таблицы.
Прозрачность тиражирования. В общем случае, тиражирование
– это асинхронный процесс переноса изменений в объектах исходной
БД в базы, которые расположены на других узлах РБД. Относительно распределенных баз данных данный аспект означает, что изменения в