ОАО «Насление отечества»

Информационно-аналитический портал «Современная Россия»

Под общей редакцией Алексея Подберезкина

База данных «Современная Россия»

Руководитель проекта: Александр Немченко

Авторский коллектив: Анна Больботенко

Сергей Голубев

Екатерина Немченко

Игорь Подберезкин

Александр Царьков

Константин Чернов

г. Москва

2002

АННОТАЦИЯ.

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

Данная работа посвящена разработке базы данных «Современная Россия». База данных выполнена на основе PHP 4.1.2. и MySQL 3-23-49-max, и имеет современный интерфейс с возможностями гипертекста, что позволяет легко пользоваться им людям с минимальными навыками работы на персональных ЭВМ.

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

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

ПОСТАНОВКА ЗАДАЧИ И ТРЕБОВАНИЯ К БАЗЕ ДАННЫХ.

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

Система должна:

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

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

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

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

ВВЕДЕНИЕ.

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

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

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

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

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

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

• Определить информационные потребности базы данных.
• Проанализировать объекты реального мира, которые необходимо смоделировать в базе данных. Сформировать из этих объектов сущности и характеристики этих сущностей (например, для сущности "деталь" характеристиками могут быть "название", "цвет", "вес" и т.п.) и сформировать их список.
• Поставить в соответствие сущностям и характеристикам - таблицы и столбцы (поля) в нотации, выбранной Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle и т.д.).
• Определить атрибуты, которые уникальным образом идентифицируют каждый объект.
• Выработать правила, которые будут устанавливать, и поддерживать целостность данных.
• Установить связи между объектами (таблицами и столбцами), провести нормализацию таблиц.
• Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.

Для поддержания ссылочной целостности данных во многих СУБД имеется механизм так называемых внешних ключей. Смысл этого механизма состоит в том, что некоему атрибуту (или группе атрибутов) одного отношения назначается ссылка на первичный ключ другого отношения; тем самым закрепляются связи подчиненности между этими отношениями. При этом отношение, на первичный ключ которого ссылается внешний ключ другого отношения, называется master-отношением, или главным отношением; а отношение, от которого исходит ссылка, называется detail-отношением, или подчиненным отношением. После назначения такой ссылки СУБД имеет возможность автоматически отслеживать вопросы "не нарушения" связей между отношениями, а именно:

0. если попытаться вставить в подчиненную таблицу запись, для внешнего ключа которой не существует соответствия в главной таблице (например, там нет еще записи с таким первичным ключом), СУБД сгенерирует ошибку;
1. если попытаться удалить из главной таблицы запись, на первичный ключ которой имеется хотя бы одна ссылка из подчиненной таблицы, СУБД также сгенерирует ошибку.
2. если попытаться изменить первичный ключ записи главной таблицы, на которую имеется хотя бы одна ссылка из подчиненной таблицы, СУБД также сгенерирует ошибку.

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

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

РАЗДЕЛ 1. ОБЩИЕ ВОПРОСЫ ОРГАНИЗАЦИИ

1. Анализ современного состояния компьютеризации.

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

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

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

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

Компьютеру удалось нечто грандиозное: он не просто изменил среду обитания человека, но создал новую - не отменяя старой, а просто «поверх», параллельно. Будучи проекцией интеллекта, он - проекция и того, частью чего интеллект, строго говоря, является: способности, а главное, потребности человека создавать альтернативные - параллельные, другие - миры. Грубо говоря: человеку нужно Другое, и он всегда его себе создавал. А с возникновением цифровых информационных технологий для этого появились великолепные технические средства. Конечно, у них были предшественники - в том числе и сугубо технические: фотография, кинематограф, радио, звукозапись… Но компьютерная техника стала делать это неизмеримо полнее.

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

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

1.2. Организация доступа к удаленным Базам Данных средствами Интернет.

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

Для того чтобы организовать доступ к удаленным базам данных с помощью CGI-скриптов, необходимо чтобы CGI-скрипт выполнял следующие функции:

1) Обработку строки-запроса, при условии, что метод передачи данных GCI-скрипту POST и тип MIME передаваемых данных application/x-www-form-encoded;

2) работу с файлами баз данных

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

Однако специфика рассматриваемой предметной области заключается в том, что формируемые запросы имеют сложную и нерегулярную структуру. Поэтому была решена задача по созданию средств автоматизации подобного рода приложений, а именно был разработан язык описания экранных форм, на основе которых строится страница запроса, универсальный CGI-скрипт, включающий в себя процедуру анализа запроса формата x-www-form-encoded, процедуру генерации SQL-запроса и SQL-интерпретатор.

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

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

1.2.1. Основные функции СУБД

Более точно, к числу функций СУБД принято относить следующие:

1.2.1.1. Непосредственное управление данными во внешней памяти

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

1.2.1.2. Управление буферами оперативной памяти

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

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

1.2.1.3. Управление транзакциями

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

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

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

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

1.2.1.4. Журнализация

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

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

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

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

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

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

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

1.2.1.5. Поддержка языков БД

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рссмотрим примеры существующих программных средств, которые пригодны для создания Баз Данных:

Общая характеристика продуктов Oracle

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

3. FIPS 127-2, ANSI X3-135.1992 - для БД;
4. NCSC TDI C2, B1, ITSEC F - C2/E3, F - B1/B3 - по защите данных;
5. OSI, DNSIX (MaxSix), SNMP - для сети;
6. ODBC, TSIG, X/Open, DCE, DDE, OLE, OCX, VBX - для взаимодействия приложений.

Система управления базами данных ORACLE, разработанная корпорацией Oracle, Inc., относится к реляционным системам баз данных. В настоящее время ORACLE является одной из наиболее мощных промышленных СУБД, занимая одно из ведущих мест в мире среди систем управления реляционными БД. Ее особенностью является клиент/серверная архитектура, обеспечивающая высокий уровень независимости данных, их рациональную логическую и физическую структуру, эффективное управление использованием дискового пространства и гибкость доступа к данным. Таким образом, архитектура ORACLE предполагает наличие трех составляющих: сервера, клиента и сети (с коммуникационным программным обеспечением). В роли такого обеспечения выступает пакет SQL*Net. В этой книге представлена СУБД ORACLE версии 7.0, хотя в настоящее время уже имеется более высокая версия системы.

Общая характеристика продуктов MSSQL

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

Симметричная мультипроцессорная архитектура MS SQL Server предусматривает использование "родных" сервисов операционной системы Windows NT для управления потоками (threads), памятью, операциями дискового чтения/записи, сетевыми службами, функциями безопасности, а также для поддержки параллельного выполнения потоков на нескольких CPU. Использование потоков Windows NT позволяет MS SQL Server автоматически масштабироваться при работе на многопроцессорных платформах, что исключает необходимость дополнительной конфигурации или программной настройки. Например, на Comdex была продемонстрирована работа MS SQL Server на платформе AlphaServer 8400 производства Digital, оснащенным 12 процессорами, 28 Гбайт памяти и 39-ти терабайтным хранилищем. В отличие от большинства распространенных СУБД, вынужденных иметь в своем составе механизмы дублирования ядра операционной системы для обеспечения кросс-платформенной переносимости, MS SQL Server обладает достаточно легковесной прозрачной архитектурой, не перетяжеленной несвойственными ей функциями. В результате, например, при смене типа процессора не требуется заново приобретать MS SQL Server для новой аппаратной платформы. Он ставится, по определению, на все, на чем работает Windows NT (на сегодня это Intel, Alpha, MIPS и PowerPC). По мере того как Windows NT завоевывает все большее признание, и все ведущие производители СУБД уже выпустили версии своих продуктов под этой операционной системой или уже заявили о своей готовности это сделать в ближайшее время, изначальная ориентированность MS SQL Server 6.5 на тесную интеграцию с Windows NT выступает в качестве одного из серьезных преимуществ.

На каждое пользовательское соединение в MS SQL Server назначается отдельный рабочий поток (порядка 55К) в рамках единого серверного процесса. Так как каждый из этих потоков в действительности является потоком Win32, на них распространяются соответствующие функции контроля операционной системы, включая защиту памяти, правила доступа к оборудованию и планирование выполнения потоков во времени (thread scheduling). Это предоставляет улучшенные способности к масштабированию при росте числа одновременно работающих пользователей, динамическую балансировку при загрузке процессоров и повышенную надежность, так как пользовательские запросы, исполняющиеся на разных потоках, защищены друг от друга. Несмотря на то что пул соединений ограничен 1024 потоками, динамическое управление пользовательскими соединениями и свободными потоками позволяет увеличить эту величину до 32 767. Кроме этого, другие пулы потоков могут использоваться для параллельного выполнения операций сканирования данных, удаления и обновления, резервного копирования, проверки целостности базы, индексирования, асинхронного опережающего чтения данных в кэш на основе алгоритмов предсказания, создания и управления курсорами и т. д.

Сетевые службы Windows NT обеспечивают MS SQL Server поддержку протоколов TCP/IP, NWLink IPX/SPX, Named Pipes (NetBEUI), Banyan Vines, AppleTalk (ADSP) и DECNet. В версии 6.5 к ним добавилась дополнительная сетевая библиотека - multiprotocol network library, которая "умеет слушать" порты TCP/IP, сокеты SPX или поименованные каналы (named pipes), которые обычно выбираются динамически. Несомненным достоинством multiprotocol является наличие сетевого сервиса, обеспечивающего взаимодействие между процессами при помощи вызовов удаленных процедур, что позволяет, например, использовать шифрование при передаче данных.

Общая характеристика продуктов Informix.

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

Сейчас продукты Informix уже установлены практически на всех UNIX-компьютерах. Среди всех ОЕМ фирма выбрала шесть стратегических партнеров. Это: Sequent, HP, SUN, IBM, Siemens Nixdorf, NCR. Портирование продуктов фирмы на производимые стратегическими партнерами платформы производится в первую очередь. Практически это означает, что при появлении на рынке новой платформы или новой версии операционной системы для платформы уже имеется соответствующая версия продуктов Informix.

Среди не UNIX платформ Informix поддерживает NetWare, Windows, Windows NT и DOS.

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

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

Начиная с версии 4.0 фирма Informix поставляет сервер базы данных OnLine, который поддерживает аппарат распределенных транзакций (технология OLTP - on-line transaction processing), что позволяет по-новому подходить к созданию баз данных с очень большим объемом хранимой информации.

Кроме того, в Informix-OnLine включен новый тип данных - битовые поля (BLOB - binary large objects). Битовые поля могут использоваться для мультимедийных приложений (хранение изображений и звука).

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

Сервер базы данных (database engine), он же ядро базы данных - это отдельная программа, выполняемая как отдельный процесс. Сервер передает выбранную из базы информацию по каналу клиенту. Именно сервер работает с данными, заботится об их размещении на диске. Технологию "клиент-сервер" со стороны сервера обеспечивают модули Informix-SE, Informix-Online или Informix OnLine-Dynamic Server.

Informix-SE представляет собой сервер базы данных, предназначенный для обеспечения работы в системах с малым или средним объемом информации.

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

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

Informix-OnLine - это сервер второго поколения, обеспечивающий технологию распределенных транзакций (OLTP - on-line transaction processing). Технология распределенных транзакций позволяет выполнять запросы в распределенной базе данных, физически находящихся на различных компьютерах. По сравнению с Informix-SE сервер Informix-OnLine имеет специальный тип данных - битовые поля (BLOB - Binary Large Objects), символьные строки переменной длины, буферизацию транзакций, зеркальный диск, автоматическое восстановление после системных сбоев, большую скорость (в 2-4 раза).

Модуль Informix-Star является средством поддержки работы с распределенными базами данных. Посредством модуля InformixStar осуществляется оперативная обработка транзакций.

Работа сервера Informix заключается в запуске специальной программы (SQLEXEC для Informix-SE и SQLTURBO для Informix-OnLine), которая обеспечивает работу всех SQL-операторов. Для каждого клиента запускается процесс операционной системы, использующий эту программу. В случае, если клиент прервал работу, но не вышел из своей задачи, то его процесс занимает ресурсы системы, снижая ее производительность.

Одним из последних достижений фирмы стал выпуск нового сервера базы данных OnLine Dynamic Server, которой входит в состав системы начиная с версии 6.0. Этот продукт основан на так называемой Динамической Масштабируемой Архитектуре (Dynamically Scalable Architecture - DSA), которая специально ориентирована на работу с многопроцессорными системами. OnLine Dynamic Server обеспечивает повышение производительности за счет гибкости использования ресурсов СУБД, использование многопоточной архитектуры. Фактически OnLine Dynamic Server берет на себя многие связанные с распределением ресурсов функции операционной системы. В результате уменьшается нагрузка на операционную системы, что, в конечном счете, приводит к росту производительности.

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

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

В версии 6.0 сетевые функции заложены в ядре СУБД. Поэтому для функционирования в сети OnLine Dynamic Server модули Informix-Net или Informix-Star не требуются.

Общая характеристика продуктов MySQL.

SQL СУБД (реляционная) без излишеств (правда, в последней версии появились транзакции с помощью Berkley DB и INNOBASE), зато быстрая (для поиска и добавления, если предстоят частые изменения, то лучше поискать другую СУБД). Стандарты: entry level SQL92, ODBC levels 0-2.

Лицензия - GPL/LGPL (но в случае извлечения прибыли от MySQL фирма - MySQL AB, Швеция - мягко намекает на оплату поддержки). Для хостинга лицензия не нужна, но клиенты должны иметь возможность убедиться, что все установлено правильно (предлагается давать доступ на чтение к установленным исходникам).

Написана на C и C++. Базовая платформа: Solaris 2.7-2.8, SuSE Linux 7.1 (ядро 2.4, ReiserFS), но работает также в AIX, BSDI, DEC Unix, FreeBSD, HP-UX, Linux 2.0, Mac OS X, NetBSD, OpenBSD, OS/2, SGI Irix, SunOS, SCO OpenServer, SCO UnixWare, Tru64, Win9x, NT, Win2000.

Многопотоковая. Первоначально мимикрировала под mSQL. API для C, C++, Java, Eiffel, Perl, PHP, Python, Tcl. ODBC. Парольная защита (пароли шифруются перед пересылке, это, однако, не увеличивает безопасность).

Таблицы в виде B-tree со сжатием индекса. До 32 индексов на таблицу. До 16 колонок на индекс. Длина индекса до 500 байт. Таблицы в памяти. Записи переменной длины. Есть примеры использования MySQL с 60000 таблиц и 5 миллиардами строк. Отсутствует memory leak (проверено Purify). Поддержка koi8-r и cp1251 (сортировка, сравнение и т.д.). Клиенты могут соединяться по TCP/IP (можно использовать только, если никто не подслушивает) или Unix socket. Можно встраивать в свои программы.

Стабильность подсистем: ISAM - стабильная, MyISAM - gamma, C API - стабильная (буфер до 16МБ), mysql(,admin,show,dump,import) - стабильные, Basic SQL - стабильная, оптимизатор - стабильная, блокировка (одновременный доступ нескольких процессов, не клиентов) - gamma (проблемы в Linux, рекомендуется --skip-locking), нити в Linux - рекомендуется --skip-locking и использовать не более 1000 одновременных соединений, DBD - стабильная, MyODBC - gamma, репликация - бета/gamma, BDB - бета (транзакции), автоматическое восстановление MyISAM - бета, слияние таблиц - бета/gamma, INNODB - альфа (транзакции с блокировкой на уровне строк), полнотекстовый поиск - бета.

Расширения к ANSI SQL92:

7. типы полей MEDIUMINT, SET, ENUM и различные модификации BLOB и TEXT
8. атрибуты полей: AUTO_INCREMENT, BINARY, NULL, UNSIGNED и ZEROFILL
9. по умолчанию строки сравниваются независимо от регистра
10. ключевые слова TEMPORARY и IF NOT EXISTS при создании/удалении таблиц
11. ключ DELAYED при создании/замене строк
12. ключ LOW_PRIORITY при манипуляции со строками
13. SHOW
14. строки можно заключать не только в апострофы, но и в кавычки
15. SET OPTION
16. синонимы операторов OR (||) и AND (&&) и MOD (%)
17. LAST_INSERT_ID()
18. REGEXP
19. IT_COUNT(), CASE, ELT(), FROM_DAYS(), FORMAT(), IF(), PASSWORD(), ENCRYPT(), md5(), ENCODE(), DECODE(), PERIOD_ADD(), PERIOD_DIFF(), TO_DAYS(), or WEEKDAY()
20. REPLACE вместо DELETE + INSERT
21. присвоение значений переменным в выражениях
22. комментарии в стиле C и sh
23. множество других мелких улучшений и несовместимостей, которые не позволят Вам "соскочить" с MySQL на другую СУБД

Отсутствующие возможности ANSI SQL92:

24. sub-select (в руководстве приводятся примеры как обойтись без него)
25. хранимые процедуры и тригеры (тригеры не планируются совсем)
26. FOREIGN KEY
27. views

РАЗДЕЛ II. СПЕЦИАЛЬНАЯ ЧАСТЬ.

2.1. Цель создания БД «Современная Россия».

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

2.2. Анализ структуры и организации БД.

2.2.1. Интерфейс пользователя.

Должен предусматривать процедуру регистрации, систему поиска подобного поисковой машине (Yandex, Rambler) и систему подробного поиска.

2.2.2. Интерфейс редактора.

Должен давать возможность вводить и редактировать записи в БД с удаленного компьютера через Интернет.

2.2.3. Интерфейс администратора.

Должен давать возможность администрирования БД.

2.3. Требования к БД.

1. Все применяемые программные средства должны быть свободно распространяемыми, т.е. проект должен быть лицензионно чист.
2. Предполагаемый объем хранимой и доступной через Интернет для пользователя информации составляет от 10 до 100 Гб.
3. Время поиска не более 10 секунд.
4. Информация в БД должна быть структурирована по рубрикам, причем каждая запись в БД может принадлежать более чем одной рубрике. Степень вложения рубрик – не более трех.
5. Записи в БД должны иметь следующие реквизиты:
1. Обязательно:

• Источник (может быть более одного);
• Рубрика (может быть более одной);
• Язык публикации (один);
• Заголовок (один);
• Публикуемый текст (один);

2. Не обязательно:

• Автор (может быть более одного);
• Два подзаголовка;
• Аннотация к тексту;
• Дата и место публикации;
• Ключевое слово (для индикации и поиска);
• Служебное поле (для отметок редактора, не доступное обычным пользователям);

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

2.4. Выбор и обоснование технических решений.

2.4.1. Выбор платформы.

В качестве платформы для WEB сервера выбрана операционная среда Free BSD, функционирующая на сервере следующей конфигурации: Pentium 3 – 1000 Dual, память 512 Мб, RAID 120 Кб. В качестве устройства Backup применяется пишущий CD-RW.

FreeBSD - это мощная операционная система семейства BSD UNIX для компьютеров архитектур, совместимых с Intel ia32, DEC Alpha и PC-98. Корни ее идут из BSD UNIX, версии UNIX разработанной в Университете Калифорнии, Беркли. Она разрабатывается и поддерживается большой командой разработчиков. Поддержка других платформ находится на разных стадиях разработки.

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

FreeBSD является идеальной платформой для построения Internet или Intranet. Эта система предоставляет надёжные даже при самой интенсивной нагрузке сетевые службы, и эффективное управление памятью, что позволяет обеспечивать приемлемое время отклика для сотен и даже тысяч одновременно работающих пользовательских задач.

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

FreeBSD может быть установлена с различных носителей, включая CD-ROM, дискеты, магнитную ленту, раздел MS-DOS, или если у вас есть подключение к сети, то вы можете установить её непосредственно через FTP или NFS. Хотя вы можете предположить, что операционная система с такими возможностями продаётся по высокой цене, FreeBSD распространяется бесплатно и поставляется со всеми исходными текстами.

2.4.2. Организация доступа в Интернет.

Включение в Интернет осуществляется посредством интерфейса Ethernet канал 128К.

Ethernet современный сетевой стандарт позволяющий организовать взаимодействие компьютеров на высоких скоростях с высокой степенью надежности.

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

Технические данные	Ethernet	Dialup
1. Средняя скорость обмена данными (Мбит/сек)	100	0,005
2. Время подключения (организации сеанса связи, сек)	1-5	30-180
3. Среднее количество сбоев на 100 часов эксплуатации	1-2	100-200
4. Стоимость трафика	0,12 $/Гб	0,60 $/мин.