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

ОАО «Насление отечества»
Информационно-аналитический портал «Современная Россия»
Под общей редакцией Алексея Подберезкина
База данных
«Современная Россия»
Руководитель проекта:
Авторский коллектив:
г. Москва
2002
Александр Немченко
Анна Больботенко
Сергей Голубев
Екатерина Немченко
Игорь Подберезкин
Александр Царьков
Константин Чернов
АННОТАЦИЯ.
Основные
идеи
современной
информационной
технологии
базируются на концепции, согласно которой данные должны быть
организованны в базы данных с целью адекватного отображения
изменяющегося реального мира и удовлетворения информационных
потребностей пользователей. Эти базы данных создаются и
функционируют
под
управлением
специальных
программных
комплексов, называемых системами управления базами данных
(СУБД).
Данная работа посвящена разработке базы данных «Современная
Россия». База данных выполнена на основе PHP 4.1.2. и MySQL 323-49-max, и имеет современный интерфейс с возможностями
гипертекста, что позволяет легко пользоваться им людям с
минимальными навыками работы на персональных ЭВМ.
Увеличение объема и структурной сложности, хранимых данных,
расширение круга пользователей информационных систем привели
к широкому распространению наиболее удобных и сравнительно
простых для понимания реляционных (табличных) СУБД. Для
обеспечения
одновременного
доступа
к
данным
множества
пользователей, нередко расположенных достаточно далеко друг от
друга и от места хранения баз данных, созданы сетевые
мультипользовательские версии СУБД. В них тем или иным путем
решаются специфические проблемы параллельных процессов,
целостности (правильности) и безопасности данных, а также
санкционирования доступа.
Для работы требуются минимальные аппаратные средства. И
следует отметить, что роль разработок на данную тему сейчас
весьма актуальна, так как непрерывный рост быстродействия,
2
размеров и стоимости компьютеров привели к резкому расширению
возможных рынков их сбыта, круга пользователей, разнообразия
типов и цен. Естественно, что расширился спрос на разнообразное
программное обеспечение.
ПОСТАНОВКА ЗАДАЧИ И ТРЕБОВАНИЯ К БАЗЕ ДАННЫХ.
Разработать и создать программный продукт, который можно
отнести к базам данных, интеллектуальным информационнопоисковым системам.
Система должна:
- Удовлетворять всем требованиям пользователей к содержимому
базы данных. Перед проектированием базы необходимо провести
обширные
исследования
требований
пользователей
к
функционированию базы данных.
- Гарантировать непротиворечивость и целостность данных. При
проектировании таблиц нужно определить их атрибуты и
некоторые
правила,
ограничивающие
возможность
ввода
пользователем неверных значений. Для верификации данных
перед непосредственной записью их в таблицу база данных
должна осуществлять вызов правил модели данных и тем самым
гарантировать сохранение целостности информации.
- Обеспечивать
естественное,
легкое
для
восприятия
структурирование информации. Качественное построение базы
позволяет делать запросы к базе более "прозрачными" и легкими
для понимания; следовательно, снижается вероятность внесения
некорректных данных и улучшается качество сопровождения
базы.
3
- Удовлетворять требованиям пользователей к производительности
базы данных. При больших объемах информации вопросы
сохранения производительности начинают играть главную роль,
сразу "высвечивая" все недочеты этапа проектирования.
ВВЕДЕНИЕ.
Во всей истории вычислительной техники можно проследить две
основных области ее использования. Первая область - применение
вычислительной техники для выполнения численных расчетов,
которые слишком долго или вообще невозможно производить
вручную.
Вторая область - это использование средств вычислительной
техники
в
информационных
информационная
автоматических
системах.
система
или
В
самом
представляет
автоматизированных
широком
собой
смысле
программно-
аппаратный комплекс, функции которого состоят в надежном
хранении
информации
специфических
для
в
памяти
данного
компьютера,
приложения
выполнении
преобразований
информации и/или вычислений, предоставлении пользователям
удобного и легко осваиваемого интерфейса. Обычно такие системы
имеют дело с большими объемами информации, и эта информация
имеет достаточно сложную структуру. Классическими примерами
информационных систем являются банковские системы, системы
резервирования авиационных или железнодорожных билетов, мест в
гостиницах и т. д.
Вторая область использования вычислительной техники возникла
несколько позже первой. Это связано с тем, что на заре
вычислительной техники возможности компьютеров по хранению
4
информации были очень ограниченными. Говорить о надежном и
долговременном хранении информации можно только при наличии
запоминающих
устройств,
сохраняющих
информацию
после
выключения электрического питания. Оперативная (основная)
память компьютеров этим свойством обычно не обладает. В первых
компьютерах использовались два вида устройств внешней памяти магнитные ленты и барабаны. Емкость магнитных лент была
достаточно
велика,
но
по
своей
физической
природе
они
обеспечивали последовательный доступ к данным. Магнитные же
барабаны (они больше всего похожи на современные магнитные
диски
с
фиксированными
головками)
давали
возможность
произвольного доступа к данными, но были ограниченного размера.
Жизненный цикл любого программного продукта, в том числе и
системы управления базой данных, состоит (по крупному) из стадий
проектирования, реализации и эксплуатации.
Естественно, наиболее значительным фактором в жизненном цикле
приложения, работающего с базой данных, является стадия
проектирования. От того, насколько тщательно продумана структура
базы, насколько четко определены связи между ее элементами,
зависит
производительность
системы
и
ее
информационная
насыщенность, а значит - и время ее жизни.
Следующие пункты представляют основные шаги проектирования
базы данных:
 Определить информационные потребности базы данных.
 Проанализировать объекты реального мира, которые необходимо
смоделировать в базе данных. Сформировать из этих объектов
сущности и характеристики этих сущностей (например, для
сущности "деталь" характеристиками могут быть "название",
"цвет", "вес" и т.п.) и сформировать их список.
5
 Поставить в соответствие сущностям и характеристикам таблицы и столбцы (поля) в нотации, выбранной Вами СУБД
(Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase,
Informix, Oracle и т.д.).
 Определить
атрибуты,
которые
уникальным
образом
идентифицируют каждый объект.
 Выработать
правила,
которые
будут
устанавливать,
и
поддерживать целостность данных.
 Установить связи между объектами (таблицами и столбцами),
провести нормализацию таблиц.
 Спланировать
вопросы
надежности
данных
и,
при
необходимости, сохранения секретности информации.
Для поддержания ссылочной целостности данных во многих СУБД
имеется механизм так называемых внешних ключей. Смысл этого
механизма состоит в том, что некоему атрибуту (или группе
атрибутов) одного отношения назначается ссылка на первичный
ключ
другого
отношения;
тем
самым
закрепляются
связи
подчиненности между этими отношениями. При этом отношение, на
первичный ключ которого ссылается внешний ключ другого
отношения,
называется
master-отношением,
или
главным
отношением; а отношение, от которого исходит ссылка, называется
detail-отношением,
или
подчиненным
отношением.
После
назначения такой ссылки СУБД имеет возможность автоматически
отслеживать вопросы "не нарушения" связей между отношениями, а
именно:
 если попытаться вставить в подчиненную таблицу запись, для
внешнего ключа которой не существует соответствия в
6
главной таблице (например, там нет еще записи с таким
первичным ключом), СУБД сгенерирует ошибку;
 если попытаться удалить из главной таблицы запись, на
первичный ключ которой имеется хотя бы одна ссылка из
подчиненной таблицы, СУБД также сгенерирует ошибку.
 если попытаться изменить первичный ключ записи главной
таблицы, на которую имеется хотя бы одна ссылка из
подчиненной таблицы, СУБД также сгенерирует ошибку.
Таким образом, СУБД решают множество проблем, которые
затруднительно или вообще невозможно решить при использовании
файловых систем. При этом существуют приложения, для которых
вполне достаточно файлов, приложения, для которых необходимо
решать, какой уровень работы с данными во внешней памяти для
них требуется, и приложения, для которых, безусловно, нужны базы
данных.
Современные системы управления файлами и управления базами
данных представляют собой весьма совершенные инструменты,
каждый из которых может быть очень успешно применен в
соответствующей области деятельности. Но всегда необходимо
помнить, что каждый инструмент приносит максимальную пользу
именно в той области, для которой он создан.
7
РАЗДЕЛ 1. ОБЩИЕ ВОПРОСЫ ОРГАНИЗАЦИИ
1.1 Анализ современного состояния компьютеризации.
В последние десятилетия только что ушедшего века у человека
появился новый партнер по взаимодействию. Появился он вначале в
скромной роли: как инструмент и посредник. Но посредник
настолько
своеобразный,
что
в
традиционные
структуры
взаимодействия «человек-человек» и «человек-реальность» он
постепенно вклинился на правах полноценного третьего. И это стало
постепенно менять сразу всех участников триады: и людей, и самого
партнера-посредника, и реальность.
Машины, собственно, были посредниками между человеком и
реальностью с очень давних пор. Но ситуация стала приобретать
много новых черт, как только этой машиной оказался компьютер.
Особенно, когда он стал посредником между человеком и
человеком.
В принципе, компьютер отнюдь не задумывался как средство
общения. Задачи у него первоначально, в проекте, были совсем
другие. Компьютер вначале должен был, грубо говоря, считать, как
видно из его названия. Роль средства коммуникации он себе
«присвоил», - а затем сделал главной, а там и культурообразующей.
Произошло при этом нечто чрезвычайно существенное: он сложнейшая машина - стал предметом повседневного воздействия
непрофессионалов. Которые хотели от него - и по сей день хотят - в
первую очередь общения (друг с другом и с миром) и игр. Именно в
этом процессе и в этих целях компьютер создал нечто совершенно
особенное: информационную среду, а с нею и Виртуальную
Реальность. А сам, в свою очередь, превратился, чуть ли не в
8
субъект культурного процесса - и уж во всяком случае, в партнера
по общению, - который вносит в общение свои особенности, свой
ритм, свои интонации… Словом, он стал казаться человеку чем-то
весьма самостоятельным.
Компьютеру удалось нечто грандиозное: он не просто изменил среду
обитания человека, но создал новую - не отменяя старой, а просто
«поверх», параллельно. Будучи проекцией интеллекта, он - проекция
и того, частью чего интеллект, строго говоря, является: способности,
а главное, потребности человека создавать альтернативные параллельные, другие - миры. Грубо говоря: человеку нужно Другое,
и он всегда его себе создавал. А с возникновением цифровых
информационных технологий для этого появились великолепные
технические средства. Конечно, у них были предшественники - в
том числе и сугубо технические: фотография, кинематограф, радио,
звукозапись…
Но
компьютерная
техника
стала
делать
это
неизмеримо полнее.
До самого конца 70-х слово «виртуальность» не ассоциировалось ни
с электронными, ни с информационными технологиями: оно
скромно оставалось синонимом «возможного», пока в речевом
обиходе сотрудников Массачусетского технологического института
(того самого, где все начинал Норберт Винер) не начал мелькать
эффектный оборот: «виртуальная реальность». Так стали называть
трехмерные
макромодели
«большой»
реальности,
которые
создавались с помощью компьютера и давали эффект полного
присутствия в этих псевдореальностях человека.
Причем полностью идея виртуальной реальности воплощается
именно тогда, когда между ней и человеком не остается никакого
зазора: он живет в ней, как в настоящей. В пределе, в идеале, в
замысле, она во всех смыслах замещает собой «первую» реальность.
9
С виртуальными (…по происхождению) объектами даже уже сейчас
(а дальше-то что будет?!.) - благодаря современным техническим
разработкам - возможен «непосредственный физический» контакт:
их можно не только видеть (разумеется, в трехмерном изображении
- это обеспечивает специальная оптика) и слышать, но и, например,
передвигать и вообще осязать (для этого существует специальная
«перчатка данных», имитирующая все чувственные сигналы,
которые могли бы поступить при ощупывании предмета). И отсюда
уже только шаг (да и то не очень большой) от имитации уже
существующей
реальности
до
симулирования
никогда
не
существовавшей.
1.2. Организация доступа к удаленным Базам Данных
средствами Интернет.
Одной из актуальных задач в области сетевых информационных
технологий является организация доступа к удаленным базам
данных средствами Интернет. Общий механизм основан на том что,
создаются CGI-скрипты, которые обеспечивают как интерфейс с
клиентом, так и с базой данных.
Для того чтобы организовать доступ к удаленным базам данных с
помощью CGI-скриптов, необходимо чтобы CGI-скрипт выполнял
следующие функции:
1) Обработку строки-запроса, при условии, что метод передачи
данных GCI-скрипту POST и тип MIME передаваемых данных
application/x-www-form-encoded;
2) работу с файлами баз данных
10
К сожалению, общая тенденция создания прикладных CGI-скриптов
сводится к тому, что для решения каждой задачи пишется
уникальный CGI-скрипт.
Однако
специфика
рассматриваемой
предметной
области
заключается в том, что формируемые запросы имеют сложную и
нерегулярную структуру. Поэтому была решена задача по созданию
средств автоматизации подобного рода приложений, а именно был
разработан язык описания экранных форм, на основе которых
строится
страница
запроса,
универсальный
CGI-скрипт,
включающий в себя процедуру анализа запроса формата x-wwwпроцедуру
form-encoded,
генерации
SQL-запроса
и
SQL-
интерпретатор.
Описание того, как устроена форма, содержится в текстовом файле.
В этом файле описываются поля ввода (их имена и тип) и шаблон,
который содержит список условий и логических выражений,
необходимых для создания SQL-запроса. На основе этого описания
специальная утилита генерирует HTML-страницу с формой.
На
сервере
в
каталоге
выполнения
сценариев
находится
универсальный CGI-скрипт, который получает данные из формы,
анализирует их, составляет SQL-запрос и передает управление SQLинтерпретатору.
SQL-интерпретатор
обрабатывает
SQL-запрос,
осуществляет выборку и формирует выходной поток, содержащий
результаты выборки.
1.2.1. Основные функции СУБД
Более точно, к числу функций СУБД принято относить следующие:
11
1.2.1.1. Непосредственное управление данными во внешней
памяти
Эта функция включает обеспечение необходимых структур внешней
памяти как для хранения данных, непосредственно входящих в БД,
так и для служебных целей, например, для убыстрения доступа к
данным в некоторых случаях (обычно для этого используются
индексы). В некоторых реализациях СУБД активно используются
возможности существующих файловых систем, в других работа
производится вплоть до уровня устройств внешней памяти. Но
подчеркнем, что в развитых СУБД пользователи в любом случае не
обязаны знать, использует ли СУБД файловую систему, и если
использует, то, как организованы файлы. В частности, СУБД
поддерживает собственную систему именования объектов БД.
1.2.1.2. Управление буферами оперативной памяти
СУБД обычно работают с БД значительного размера; по крайней
мере, этот размер обычно существенно больше доступного объема
оперативной памяти. Понятно, что если при обращении к любому
элементу данных будет производиться обмен с внешней памятью, то
вся система будет работать со скоростью устройства внешней
памяти. Практически единственным способом реального увеличения
этой скорости является буферизация данных в оперативной памяти.
При
этом,
даже
если
операционная
система
производит
общесистемную буферизацию (как в случае ОС UNIX), этого
недостаточно для целей СУБД, которая располагает гораздо
большей информацией о полезности буферизации той или иной
части БД. Поэтому в развитых СУБД поддерживается собственный
набор буферов оперативной памяти с собственной дисциплиной
замены буферов.
12
Стоит заметить, что существует отдельное направление СУБД,
которое ориентировано на постоянное присутствие в оперативной
памяти всей БД. Это направление основывается на предположении,
что в будущем объем оперативной памяти компьютеров будет
настолько велик, что позволит не беспокоиться о буферизации. Пока
эти работы находятся в стадии исследований.
1.2.1.3. Управление транзакциями
Транзакция
-
это
последовательность
операций
над
БД,
рассматриваемых СУБД как единое целое. Либо транзакция
успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД,
произведенные этой транзакцией, во внешней памяти, либо ни одно
из этих изменений никак не отражается на состоянии БД. Понятие
транзакции необходимо для поддержания логической целостности
БД. Поддержание механизма транзакций является обязательным
условием даже однопользовательских СУБД (если, конечно, такая
система заслуживает названия СУБД). Но понятие транзакции
гораздо более важно в многопользовательских СУБД.
То свойство, что каждая транзакция начинается при целостном
состоянии БД и оставляет это состояние целостным после своего
завершения,
делает
очень
удобным
использование
понятия
транзакции как единицы активности пользователя по отношению к
БД.
При
соответствующем
управлении
параллельно
выполняющимися транзакциями со стороны СУБД каждый из
пользователей может в принципе ощущать себя единственным
пользователем
СУБД
(на
самом
деле,
это
несколько
идеализированное представление, поскольку в некоторых случаях
пользователи
многопользовательских
СУБД
могут
ощутить
присутствие своих коллег).
13
С управлением транзакциями в многопользовательской СУБД
связаны важные понятия сериализации транзакций и сериального
плана
выполнения
смеси
транзакций.
Под
сериализацией
параллельно выполняющихся транзакций понимается такой порядок
планирования их работы, при котором суммарный эффект смеси
транзакций эквивалентен эффекту их некоторого последовательного
выполнения. Сериальный план выполнения смеси транзакций - это
такой план, который приводит к сериализации транзакций. Понятно,
что если удается добиться действительно сериального выполнения
смеси транзакций, то для каждого пользователя, по инициативе
которого образована транзакция, присутствие других транзакций
будет незаметно (если не считать некоторого замедления работы по
сравнению с однопользовательским режимом).
Существует
несколько
базовых
алгоритмов
сериализации
транзакций. В централизованных СУБД наиболее распространены
алгоритмы, основанные на синхронизационных захватах объектов
БД. При использовании любого алгоритма сериализации возможны
ситуации конфликтов между двумя или более транзакциями по
доступу к объектам БД. В этом случае для поддержания
сериализации необходимо выполнить откат (ликвидировать все
изменения, произведенные в БД) одной или более транзакций. Это
один из случаев, когда пользователь многопользовательской СУБД
может реально (и достаточно неприятно) ощутить присутствие в
системе транзакций других пользователей.
1.2.1.4. Журнализация
Одним из основных требований к СУБД является надежность
хранения данных во внешней памяти. Под надежностью хранения
понимается то, что СУБД должна быть в состоянии восстановить
14
последнее согласованное состояние БД после любого аппаратного
или программного сбоя. Обычно рассматриваются два возможных
вида аппаратных сбоев: так называемые мягкие сбои, которые
можно трактовать как внезапную остановку работы компьютера
(например, аварийное выключение питания), и жесткие сбои,
характеризуемые потерей информации на носителях внешней
памяти. Примерами программных сбоев могут быть: аварийное
завершение работы СУБД (по причине ошибки в программе или в
результате некоторого аппаратного сбоя) или аварийное завершение
пользовательской
программы,
в
результате
чего
некоторая
транзакция остается незавершенной. Первую ситуацию можно
рассматривать как особый вид мягкого аппаратного сбоя; при
возникновении последней требуется ликвидировать последствия
только одной транзакции.
Понятно, что в любом случае для восстановления БД нужно
располагать некоторой дополнительной информацией. Другими
словами, поддержание надежности хранения данных в БД требует
избыточности хранения данных, причем та часть данных, которая
используется для восстановления, должна храниться особо надежно.
Наиболее
распространенным
методом
поддержания
такой
избыточной информации является ведение журнала изменений БД.
Журнал - это особая часть БД, недоступная пользователям СУБД и
поддерживаемая с особой тщательностью (иногда поддерживаются
две копии журнала, располагаемые на разных физических дисках), в
которую поступают записи обо всех изменениях основной части БД.
В разных СУБД изменения БД журнализуются на разных уровнях:
иногда запись в журнале соответствует некоторой логической
операции изменения БД (например, операции удаления строки из
таблицы реляционной БД), иногда - минимальной внутренней
15
операции модификации страницы внешней памяти; в некоторых
системах одновременно используются оба подхода.
Во всех случаях придерживаются стратегии "упреждающей" записи
в журнал (так называемого протокола Write Ahead Log - WAL).
Грубо говоря, эта стратегия заключается в том, что запись об
изменении любого объекта БД должна попасть во внешнюю память
журнала раньше, чем измененный объект попадет во внешнюю
память основной части БД. Известно, что если в СУБД корректно
соблюдается протокол WAL, то с помощью журнала можно решить
все проблемы восстановления БД после любого сбоя.
Самая простая ситуация восстановления - индивидуальный откат
транзакции. Строго говоря, для этого не требуется общесистемный
журнал изменений БД. Достаточно для каждой транзакции
поддерживать локальный журнал операций модификации БД,
выполненных в этой транзакции, и производить откат транзакции,
путем выполнения обратных операций, следуя от конца локального
журнала. В некоторых СУБД так и делают, но в большинстве систем
локальные журналы не поддерживают, а индивидуальный откат
транзакции выполняют по общесистемному журналу, для чего все
записи от одной транзакции связывают обратным списком (от конца
к началу).
При мягком сбое во внешней памяти основной части БД могут
находиться
объекты,
модифицированные
транзакциями,
не
закончившимися к моменту сбоя, и могут отсутствовать объекты,
модифицированные транзакциями, которые к моменту сбоя успешно
завершились (по причине использования буферов оперативной
памяти, содержимое которых при мягком сбое пропадает). При
соблюдении протокола WAL во внешней памяти журнала должны
гарантированно находиться записи, относящиеся к операциям
16
модификации
обоих
видов
объектов.
Целью
процесса
восстановления после мягкого сбоя является состояние внешней
памяти основной части БД, которое возникло бы при фиксации во
внешней памяти изменений всех завершившихся транзакций и
которое
не
содержало
бы
никаких
следов
незаконченных
транзакций. Для того, чтобы этого добиться, сначала производят
откат незавершенных транзакций (undo), а потом повторно
воспроизводят
(redo)
те
операции
завершенных
транзакций,
результаты которых не отображены во внешней памяти. Этот
процесс
содержит
много
тонкостей,
связанных
с
общей
организацией управления буферами и журналом. Более подробно мы
рассмотрим это в соответствующей лекции.
Для восстановления БД после жесткого сбоя используют журнал и
архивную копию БД. Грубо говоря, архивная копия - это полная
копия БД к моменту начала заполнения журнала (имеется много
вариантов более гибкой трактовки смысла архивной копии).
Конечно, для нормального восстановления БД после жесткого сбоя
необходимо, чтобы журнал не пропал. Как уже отмечалось, к
сохранности журнала во внешней памяти в СУБД предъявляются
особо повышенные требования. Тогда восстановление БД состоит в
том, что исходя из архивной копии, по журналу воспроизводится
работа всех транзакций, которые закончились к моменту сбоя. В
принципе, можно даже воспроизвести работу незавершенных
транзакций
и
продолжить
их
работу
после
завершения
восстановления. Однако в реальных системах это обычно не
делается, поскольку процесс восстановления после жесткого сбоя
является достаточно длительным.
17
1.2.1.5. Поддержка языков БД
Для работы с базами данных используются специальные языки, в
целом
называемые
языками
баз
данных.
В
ранних
СУБД
поддерживалось несколько специализированных по своим функциям
языков. Чаще всего выделялись два языка - язык определения схемы
БД (SDL - Schema Definition Language) и язык манипулирования
данными (DML - Data Manipulation Language). SDL служил главным
образом для определения логической структуры БД, т.е. той
структуры БД, какой она представляется пользователям. DML
содержал
набор
операторов,
операторов
позволяющих
манипулирования
заносить
данные
в
данными,
БД,
т.е.
удалять,
модифицировать или выбирать существующие данные.
В
современных
СУБД
обычно
поддерживается
единый
интегрированный язык, содержащий все необходимые средства для
работы с БД, начиная от ее создания, и обеспечивающий базовый
пользовательский интерфейс с базами данных. Стандартным языком
наиболее распространенных в настоящее время реляционных СУБД
является язык SQL (Structured Query Language).
Прежде всего, язык SQL сочетает средства SDL и DML, т.е.
позволяет определять схему реляционной БД и манипулировать
данными. При этом именование объектов БД (для реляционной БД именование таблиц и их столбцов) поддерживается на языковом
уровне в том смысле, что компилятор языка SQL производит
преобразование имен объектов в их внутренние идентификаторы на
основании
специально
поддерживаемых
служебных
таблиц-
каталогов. Внутренняя часть СУБД (ядро) вообще не работает с
именами таблиц и их столбцов.
Язык
SQL
содержит
специальные
средства
определения
ограничений целостности БД. Опять же, ограничения целостности
18
хранятся
в
специальных
таблицах-каталогах,
и
обеспечение
контроля целостности БД производится на языковом уровне, т.е. при
компиляции операторов модификации БД компилятор SQL на
основании имеющихся в БД ограничений целостности генерирует
соответствующий программный код.
Специальные операторы языка SQL позволяют определять так
называемые представления БД, фактически являющиеся хранимыми
в БД запросами (результатом любого запроса к реляционной БД
является таблица) с именованными столбцами. Для пользователя
представление является такой же таблицей, как любая базовая
таблица, хранимая в БД, но с помощью представлений можно
ограничить или наоборот расширить видимость БД для конкретного
пользователя. Поддержание представлений производится также на
языковом уровне.
Наконец, авторизация доступа к объектам БД производится также на
основе специального набора операторов SQL. Идея состоит в том,
что для выполнения операторов SQL разного вида пользователь
должен
обладать
различными
полномочиями.
Пользователь,
создавший таблицу БД, обладает полным набором полномочий для
работы с этой таблицей. В число этих полномочий входит
полномочие на передачу всех или части полномочий другим
пользователям, включая полномочие на передачу полномочий.
Полномочия пользователей описываются в специальных таблицахкаталогах, контроль полномочий поддерживается на языковом
уровне.
19
1.3. Обзор существующих программных средств, пригодных для
разработки баз данных.
Применительно к системам баз данных архитектура "клиент-сервер"
интересна и актуальна главным образом потому, что обеспечивает
простое и относительно дешевое решение проблемы коллективного
доступа к базам данных в локальной сети. В некотором роде
системы баз данных, основанные на архитектуре "клиент-сервер",
являются приближением к распределенным системам баз данных,
конечно, существенно упрощенным приближением, но зато не
требующим решения основного набора проблем действительно
распределенных баз данных.
Доступ к базе данных от прикладной программы или пользователя
производится путем обращения к клиентской части системы. В
качестве основного интерфейса между клиентской и серверной
частями выступает язык баз данных SQL.
Это язык по сути дела представляет собой текущий стандарт
интерфейса СУБД в открытых системах. Собирательное название
SQL-сервер относится ко всем серверам баз данных, основанных на
SQL.
Соблюдая
предосторожности
при
программировании,
некоторые из которых были рассмотрены на предыдущих лекциях,
можно создавать прикладные информационные системы, мобильные
в классе SQL-серверов.
Серверы баз данных, интерфейс которых основан исключительно на
языке
SQL,
недостатками.
обладают
своими
Очевидное
преимуществами
преимущество
-
и
своими
стандартность
интерфейса. В пределе, хотя пока это не совсем так, клиентские
части любой SQL-ориентированной СУБД могли бы работать с
любым SQL-сервером вне зависимости от того, кто его произвел.
20
Недостаток тоже довольно очевиден. При таком высоком уровне
интерфейса между клиентской и серверной частями системы на
стороне клиента работает слишком мало программ СУБД. Это
нормально, если на стороне клиента используется маломощная
рабочая
станция. Но
если
клиентский
компьютер
обладает
достаточной мощностью, то часто возникает желание возложить на
него больше функций управления базами данных, разгрузив сервер,
который является узким местом всей системы.
Одним из перспективных направлений СУБД является гибкое
конфигурирование системы, при котором распределение функций
между клиентской и пользовательской частями СУБД определяется
при установке системы.
В типичном на сегодняшний день случае на стороне клиента СУБД
работает только такое программное обеспечение, которое не имеет
непосредственного доступа к базам данных, а обращается для этого
к серверу с использованием языка SQL.
В некоторых случаях хотелось бы включить в состав клиентской
части системы некоторые функции для работы с "локальным кэшем"
базы данных, т.е. с той ее частью, которая интенсивно используется
клиентской прикладной программой. В современной технологии это
можно сделать только путем формального создания на стороне
клиента локальной копии сервера базы данных и рассмотрения всей
системы как набора взаимодействующих серверов.
С другой стороны, иногда хотелось бы перенести большую часть
прикладной системы на сторону сервера, если разница в мощности
клиентских рабочих станций и сервера чересчур велика. В общем-то
при использовании RPC это сделать нетрудно. Но требуется, чтобы
базовое программное обеспечение сервера действительно позволяло
21
это. В частности, при использовании ОС UNIX проблемы
практически не возникают.
Рссмотрим примеры существующих программных средств, которые
пригодны для создания Баз Данных:
Общая характеристика продуктов Oracle
Все продукты Oracle (СУБД, средства разработки, средства для
конечного пользователя, сетевые компоненты) являются открытыми,
масштабируемыми
и
программируемыми.
Они
позволяют
разрабатывать приложения, как уровня небольшой рабочей группы,
так и уровня огромного предприятия с тысячами пользователей,
террабайтными базами, размещенными в различных зданиях и даже
странах.
Средства
Oracle
позволяют
надежно
защитить
эти
данные,
обеспечить их целостность и непротиворечивость. Продукты Oracle
работают более чем на ста вычислительных платформах (компьютер
+
операционная
система),
поддерживают
все
основные
промышленные сетевые протоколы и графические оконные среды.
Это позволяет с минимальными затратами переносить готовые
приложения
с
одной
платформы
на
другую.
С помощью средств Oracle возможно реализовать оперативную
обработку (OLTP - системы), системы поддержки принятия решений
(DSS - системы) и системы накопления и анализа больших объемов
данных (Data Warehouse и OLAP - системы). Oracle поддерживает
все основные стандарты:
 FIPS 127-2, ANSI X3-135.1992 - для БД;
 NCSC TDI C2, B1, ITSEC F - C2/E3, F - B1/B3 - по защите
данных;
22
 OSI, DNSIX (MaxSix), SNMP - для сети;
 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 является одним из наиболее стремительно развивающихся
серверов баз данных на рынке корпоративных СУБД. Разумеется, в
рамках данной статьи невозможно подробно остановиться на
23
характеристиках этого продукта в той мере, в какой это хотелось бы
сделать и какой он, безусловно, заслуживает. Поэтому мы
ограничим нашу задачу рассмотрением хотя бы некоторых базовых
возможностей
Microsoft
SQL
Server
6.5
применительно
к
перечисленным выше функциям сервера баз данных.
Симметричная мультипроцессорная архитектура MS SQL Server
предусматривает использование "родных" сервисов операционной
системы Windows NT для управления потоками (threads), памятью,
операциями
дискового
чтения/записи,
сетевыми
службами,
функциями безопасности, а также для поддержки параллельного
выполнения потоков на нескольких CPU. Использование потоков
Windows
NT
позволяет
MS
SQL
Server
автоматически
масштабироваться при работе на многопроцессорных платформах,
что исключает необходимость дополнительной конфигурации или
программной
настройки.
Например,
продемонстрирована
работа
AlphaServer
производства
8400
MS
SQL
на
Comdex
Server
Digital,
на
была
платформе
оснащенным
12
процессорами, 28 Гбайт памяти и 39-ти терабайтным хранилищем. В
отличие от большинства распространенных СУБД, вынужденных
иметь в своем составе механизмы дублирования ядра операционной
системы для обеспечения кросс-платформенной переносимости, MS
SQL
Server
обладает
достаточно
легковесной
прозрачной
архитектурой, не перетяжеленной несвойственными ей функциями.
В результате, например, при смене типа процессора не требуется
заново приобретать MS SQL Server для новой аппаратной
платформы. Он ставится, по определению, на все, на чем работает
Windows NT (на сегодня это Intel, Alpha, MIPS и PowerPC). По мере
того как Windows NT завоевывает все большее признание, и все
ведущие производители СУБД уже выпустили версии своих
24
продуктов под этой операционной системой или уже заявили о своей
готовности
это
сделать
в
ближайшее
время,
изначальная
ориентированность 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
25
к ним добавилась дополнительная сетевая библиотека - 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.
26
Фирма Informix объявила и поддерживает программу InSync.
Программа объединяет независимых разработчиков программного
обеспечения. В рамках этой программы созданы программные
интерфейсы для связи с СУБД других производителей, в частности
СУБД, функционирующие на не UNIX-платформах.
Продукты Informix содержат серверы баз данных, средства
разработки и отладки, коммуникационные средства. Характерной
особенностью Informix является наличие нескольких типов серверов,
подробнее о них будет сказано ниже.
Начиная с версии 4.0 фирма Informix поставляет сервер базы данных
OnLine, который поддерживает аппарат распределенных транзакций
(технология OLTP - on-line transaction processing), что позволяет поновому подходить к созданию баз данных с очень большим объемом
хранимой информации.
Кроме того, в Informix-OnLine включен новый тип данных - битовые
поля
(BLOB
-
использоваться
binary
для
large
objects).
мультимедийных
Битовые
поля
приложений
могут
(хранение
изображений и звука).
В основе систем, разработанных на основе СУБД Informix, лежит
принцип
архитектуры
пользовательская
"клиент-сервер".
прикладная
программа,
Клиент
-
это
обеспечивающая
взаимодействие (интерфейс) базы данных с пользователем. Всю
работу, связанную с доступом и модификацией базы данных,
выполняет сервер базы данных (БД-сервер).
Сервер базы данных (database engine), он же ядро базы данных - это
отдельная программа, выполняемая как отдельный процесс. Сервер
передает выбранную из базы информацию по каналу клиенту.
27
Именно сервер работает с данными, заботится об их размещении на
диске.
Технологию
"клиент-сервер"
со
стороны
сервера
обеспечивают модули Informix-SE, Informix-Online или Informix
OnLine-Dynamic Server.
Informix-SE
представляет
собой
сервер
базы
данных,
предназначенный для обеспечения работы в системах с малым или
средним объемом информации.
Хранение данных в этом случае осуществляется в файловой системе
операционной системы, что значительно упрощает разработку и
эксплуатацию приложений.
Клиенты и серверы могут находиться на одном компьютере, либо на
нескольких, связанных между собой сетью. Подобное разделение
функций дает высокую производительность и максимальную
гибкость. Для обеспечения отношений связи типа "клиент-сервер"
между различными компьютерами со стороны сервера применяется
модуль Informix-NET.
Informix-OnLine - это сервер второго поколения, обеспечивающий
технологию распределенных транзакций (OLTP - on-line transaction
processing). Технология распределенных транзакций позволяет
выполнять запросы в распределенной базе данных, физически
находящихся на различных компьютерах. По сравнению с InformixSE сервер Informix-OnLine имеет специальный тип данных - битовые
поля (BLOB - Binary Large Objects), символьные строки переменной
длины, буферизацию транзакций, зеркальный диск, автоматическое
восстановление после системных сбоев, большую скорость (в 2-4
раза).
28
Модуль Informix-Star является средством поддержки работы с
распределенными базами данных. Посредством модуля InformixStar
осуществляется оперативная обработка транзакций.
Работа сервера Informix заключается в запуске специальной
программы (SQLEXEC для Informix-SE и SQLTURBO для InformixOnLine), которая обеспечивает работу всех SQL-операторов. Для
каждого клиента запускается процесс операционной системы,
использующий эту программу. В случае, если клиент прервал
работу, но не вышел из своей задачи, то его процесс занимает
ресурсы системы, снижая ее производительность.
Одним из последних достижений фирмы стал выпуск нового сервера
базы данных OnLine Dynamic Server, которой входит в состав
системы начиная с версии 6.0. Этот продукт основан на так
называемой
Динамической
Масштабируемой
Архитектуре
(Dynamically Scalable Architecture - DSA), которая специально
ориентирована на работу с многопроцессорными системами. OnLine
Dynamic Server обеспечивает повышение производительности за
счет гибкости использования ресурсов СУБД, использование
многопоточной архитектуры. Фактически OnLine Dynamic Server
берет на себя многие связанные с распределением ресурсов функции
операционной системы. В результате уменьшается нагрузка на
операционную системы, что, в конечном счете, приводит к росту
производительности.
Для обслуживания клиентов запускаются "виртуальные процессоры"
- процессы операционной системы, которые устанавливают связь
между клиентом и ядром Informix. Связь устанавливается с
помощью специальных "нитей" (thread), которые активизируются,
29
только если клиент активен и обращается к серверу базы данных. В
случае если клиент неактивен, "нить" может обслуживать других
клиентов.
Число виртуальных процессоров определяет администратор базы
данных, исходя из реальных ресурсов вычислительной системы и
сети
клиентов.
Если
вычислительная
система
является
многопроцессорной, то разные виртуальные процессоры могут
обслуживаться разными реальными процессорами.
В версии 6.0 сетевые функции заложены в ядре СУБД. Поэтому для
функционирования в сети OnLine Dynamic Server модули InformixNet или 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
30
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:
 типы
полей
MEDIUMINT,
SET,
ENUM
и
различные
модификации BLOB и TEXT
31
 атрибуты полей: AUTO_INCREMENT, BINARY, NULL,
UNSIGNED и ZEROFILL
 по умолчанию строки сравниваются независимо от регистра
 ключевые слова TEMPORARY и IF NOT EXISTS при
создании/удалении таблиц
 ключ DELAYED при создании/замене строк
 ключ LOW_PRIORITY при манипуляции со строками
 SHOW
 строки можно заключать не только в апострофы, но и в
кавычки
 SET OPTION
 синонимы операторов OR (||) и AND (&&) и MOD (%)
 LAST_INSERT_ID()
 REGEXP
 IT_COUNT(), CASE, ELT(), FROM_DAYS(), FORMAT(), IF(),
PASSWORD(), ENCRYPT(), md5(), ENCODE(), DECODE(),
PERIOD_ADD(),
PERIOD_DIFF(),
TO_DAYS(),
or
WEEKDAY()
 REPLACE вместо DELETE + INSERT
 присвоение значений переменным в выражениях
 комментарии в стиле C и sh
 множество других мелких улучшений и несовместимостей,
которые не позволят Вам "соскочить" с MySQL на другую
СУБД
Отсутствующие возможности ANSI SQL92:
 sub-select (в руководстве приводятся примеры как обойтись
без него)
32
 хранимые процедуры и тригеры (тригеры не планируются
совсем)
 FOREIGN KEY
 views
РАЗДЕЛ II. СПЕЦИАЛЬНАЯ ЧАСТЬ.
2.1. Цель создания БД «Современная Россия».
Целью создания БД было объединить разнообразные материалы,
относящиеся к различным областям человеческой деятельности, в
единой, легко доступной среде, с возможностью пополнения и
изменения через Интернет.
2.2. Анализ структуры и организации БД.
2.2.1. Интерфейс пользователя.
Должен предусматривать процедуру регистрации, систему поиска
подобного поисковой машине (Yandex, Rambler) и систему
подробного поиска.
2.2.2. Интерфейс редактора.
Должен давать возможность вводить и редактировать записи в БД с
удаленного компьютера через Интернет.
2.2.3. Интерфейс администратора.
Должен давать возможность администрирования БД.
2.3. Требования к БД.
1. Все применяемые программные средства должны быть
свободно распространяемыми, т.е. проект должен быть
лицензионно чист.
33
2. Предполагаемый объем хранимой и доступной через Интернет
для пользователя информации составляет от 10 до 100 Гб.
3. Время поиска не более 10 секунд.
4. Информация в БД должна быть структурирована по рубрикам,
причем каждая запись в БД может принадлежать более чем
одной рубрике. Степень вложения рубрик – не более трех.
5. Записи в БД должны иметь следующие реквизиты:
5.1.
Обязательно:
- Источник (может быть более одного);
- Рубрика (может быть более одной);
- Язык публикации (один);
- Заголовок (один);
- Публикуемый текст (один);
5.2.
Не обязательно:
- Автор (может быть более одного);
- Два подзаголовка;
- Аннотация к тексту;
- Дата и место публикации;
- Ключевое слово (для индикации и поиска);
- Служебное поле (для отметок редактора, не доступное обычным
пользователям);
Каждая запись в БД в качестве приложения к публикации может
иметь неограниченное число файлов любых типов (zip, аудио,
видеофрагмент, графика и др.).
2.4. Выбор и обоснование технических решений.
2.4.1. Выбор платформы.
В качестве платформы для WEB сервера выбрана операционная
среда Free BSD, функционирующая на сервере следующей
34
конфигурации: 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.
Хотя
вы
можете
35
предположить, что операционная система с такими возможностями
продаётся по высокой цене, FreeBSD распространяется бесплатно и
поставляется со всеми исходными текстами.
2.4.2. Организация доступа в Интернет.
Включение в Интернет осуществляется посредством интерфейса
Ethernet канал 128К.
Ethernet современный сетевой стандарт позволяющий организовать
взаимодействие компьютеров на высоких скоростях с высокой
степенью надежности.
В данном случае альтернативой принятому решению был Dialup
доступ, т.е. по телефонной линии.
Технические данные
1. Средняя скорость
обмена данными
(Мбит/сек)
2. Время подключения
(организации сеанса
связи, сек)
3. Среднее количество
сбоев на 100 часов
эксплуатации
4. Стоимость трафика
Ethernet
Dialup
100
0,005
1-5
30-180
1-2
100-200
0,12 $/Гб
0,60 $/мин.
2.4.3. Выбор WEB сервера.
В качестве WEB сервера избран WEB сервер Apache 1.3.24.
WEB сервер Apache распространяется под лицензией GNU, т.е.
бесплатно, и является наилучшим решением для организации
интернет сервиса. По надежности ему нет равных. Этот продукт
распространяется в исходных текстах. В его отладке и тестировании
принимало
участие
несколько
тысяч
квалифицированных
программистов со всего мира. Для своей работы он требует
удивительно мало ресурсов.
36
2.4.4. Выбор СУБД.
В качестве СУБД выбран MySQL 3-23-49-max.
Выбор базы данных для этого проекта был не прост. На рынке
имеется
достаточное
количество
как
бесплатных,
так
и
коммерческих продуктов.
Например, Postgress, mSQL – не коммерческие продукты. Postgress
мощнее MySQL, но сложнее, а mSQL проще, но маломощный.
К коммерческим продуктам относятся такие как, Oracle, MsSQL,
Informix.
По понятным причинам выбор производился из некоммерческих
продуктов. Среди них MySQL выделяется удачным сочетанием
простоты, мощности и приспособленности к разработке интернет
проектов.
2.4.5. Выбор инструмента.
В качестве основного языка программирования выбран PHP 4.1.2.
Средства разработки позволяющие интегрировать HTML с базами
данных, делятся на языки высокого уровня и интерпретаторы. При
использовании языков высокого уровня трудоемкость при создании
даже небольшого WEB проекта исчисляется в человекогодах. При
выборе между PHP и Perl, выбор в пользу PHP был сделан по
следующим причинам:
1. Простота освоения и использования.
2. Прозрачность синтаксиса.
3. Мощные средства взаимодействия с БД.
4. Скорость работы.
По этим показателям, кроме скорости выбор был остановлен на PHP.
37
2.5. Архитектура БД.
2.5.1. Таблицы БД.
 Таблицы зарегистрированных пользователей для хранения
информации о зарегистрированных пользователях (USER).
2.
Regisration and privelege users
2.1.(7)
системы
IUSER
// основная информация о пользователе
(идентификатор)
+-----------+------------------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+-----------+------------------+------+-----+---------+----------------+
iu
int(10) unsigned
login
char(32)
passw
char(32)
privelege
tinyint(4)
PRI
NULL
auto_increment
0
+-----------+------------------+------+-----+---------+----------------+
 Таблицы для авторов и источников.
1.3
Autors and sourses
1.3.1.(3)
IAUTOR
// справочник (идентификатор) персоналий и
источников
+-------+------------------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+-------+------------------+------+-----+---------+----------------+
ia
int(10) unsigned
name1
char(128)
YES
PRI
NULL
name2
char(128)
YES
NULL
name3
char(128)
YES
year
smallint(6)
month
smallint(6) unsigned
YES
NULL
day
smallint(6)
YES
NULL
type
char(1)
unsigned
unsigned
NULL
auto_increment
NULL
YES
YES
NULL
NULL
+-------+------------------+------+-----+---------+----------------+
1.3.2.(4)
IA_EXT
// дополнительная таблица справочника
персоналий и источников
+-------------+------------------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+-------------+------------------+------+-----+---------+----------------+
last_upgr
timestamp(14)
YES
first_enter
timestamp(14)
YES
NULL
ia
int(10) unsigned
last_iu
int(10) unsigned
first_iu
int(10) unsigned
titul
varchar(128)
YES
NULL
biography
blob
YES
NULL
NULL
PRI
NULL
auto_increment
0
0
38
coordinate
varchar(128)
YES
NULL
+-------------+------------------+------+-----+---------+----------------+
 Таблицы для рубрикатора.
1.4
Rubrics
1.4.1.(6)
IHEAD
// справочник (идентификатор) рубрик
+--------+------------------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+--------+------------------+------+-----+---------+----------------+
ih
int(10) unsigned
ihu
header
PRI
NULL
int(10) unsigned
auto_increment
0
char(128)
+--------+------------------+------+-----+---------+----------------+
 Таблицы для языка.
1.2.(2)
LANGUAGE
// справочник языков
+----------+---------------------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+----------+---------------------+------+-----+---------+----------------+
il
tinyint(3) unsigned
language
char(32)
PRI
NULL
auto_increment
+----------+---------------------+------+-----+---------+----------------+
 Таблицы для документов.
3.
Documents
3.1.(11)
IDOC
// идентификаторы документа
+---------+---------------------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+---------+---------------------+------+-----+---------+----------------+
id
il
int(10) unsigned
PRI
NULL
tinyint(3) unsigned
auto_increment
0
name
char(127)
YES
keyword
char(255)
YES
access
tinyint(4) unsigned
NULL
NULL
100
+---------+---------------------+------+-----+---------+----------------+
3.2.(12)
ID_EXT
// дополнительная информация о документе
+-------------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+-------------+------------------+------+-----+---------+-------+
id
int(10) unsigned
last_upgr
timestamp(14)
YES
NULL
first_enter
timestamp(14)
YES
NULL
last_iu
int(10) unsigned
0
first_iu
int(10) unsigned
0
year
smallint(5) unsigned
PRI
YES
0
NULL
39
month
tinyint(2) unsigned
YES
day
tinyint(2) unsigned
YES
NULL
locate
varchar(127)
YES
NULL
PS
NULL
text
YES
NULL
+-------------+------------------+------+-----+---------+-------+
3.3.(14)
D_TXT
// основная БД документов
+----------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+----------+------------------+------+-----+---------+-------+
id
int(10) unsigned
pname1
varchar(127)
YES
pname2
varchar(127)
YES
abstract
blob
TXT
mediumblob
PRI
0
NULL
NULL
YES
NULL
YES
NULL
+----------+------------------+------+-----+---------+-------+
3.4.(15)
D_EXT
// приложения к БД документов
+-----------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+-----------+------------------+------+-----+---------+-------+
id_ext
int(10) unsigned
id
PRI
NULL
int(10) unsigned
auto_increment
0
gruffito
varchar(255)
YES
NULL
file_link
varchar(128)
YES
NULL
+-----------+------------------+------+-----+---------+-------+
 Таблица связей.
3.5
Link-tables
3.5.1(16)
ID_IA
// таблица связи документа с авторами и источниками
+-------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+-------+------------------+------+-----+---------+-------+
id
int(10) unsigned
0
ia
int(10) unsigned
0
+-------+------------------+------+-----+---------+-------+
3.5.2(17)
ID_IH
// таблица связи документа с рубриками
+-------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+-------+------------------+------+-----+---------+-------+
id
int(10) unsigned
ih
int(10) unsigned
PRI
0
0
+-------+------------------+------+-----+---------+-------+
40
2.6. Разработка основных программных объектов.
2.6.1. Главная форма.
Формируется из шаблона в формате HTML, путем включения в него
(шаблон) результатов запроса к базе данных. А так же других
элементов главной страницы (Поиск, Регистрация, Чаво).
Основной элемент первой страницы, формируемый на основе
запроса к БД – это рубрикатор.
2.6.2. Рубрикатор.
Формируется на основе таблицы MySQL “IHEAD”.
1.4
Rubrics
1.4.1.(6)
IHEAD
// справочник (идентификатор) рубрик
+--------+------------------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+--------+------------------+------+-----+---------+----------------+
ih
ihu
header
int(10) unsigned
int(10) unsigned
PRI
NULL
auto_increment
0
char(128)
+--------+------------------+------+-----+---------+----------------+
Запросы MySQL формируют 3 уровня вложенности рубрикатора:
41
Спускаясь по уровням рубрикатора пользователь получает список
публикаций (документов, единиц хранения), при этом если список
состоит более чем из 100 единиц, формируются ссылки на каждую
следующую сотню элементов списка. Выбор любого из элементов
списка приводит к отображению выходной формы документа.
2.6.3. Форма поиска.
Поиск в БД организован следующим образом. С помощью
тривиальной формы организуется ввод пользователем образца для
поиска. Образец может включать в себя до 128 символов.
Введенный
образец
анализируется
программой:
из
него
исключаются знаки пунктуации, цифры и лишние пробелы.
Полученный результат преобразуется в массив слов.
Логика поиска: в запросе к БД участвуют все элементы полученного
массива слов, связанные логическим оператором «ИЛИ» , т.е. в БД
происходит поиск каждого из слов (элементов массива). Например,
если пользователь запросил «Федеральные округа России», то в
42
результате запроса будут включены и «Федеральные законы», и
«Избирательные округа» и все документы, содержащие слово
«Россия».
Структура БД организована таким образом:
Structure tables DB naslDB
1.
References
1.1.(1)
COUNTRY
// справочник стран
+-------+-----------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+-------+-----------+------+-----+---------+----------------+
itype
int(11)
type
char(128)
PRI
NULL
auto_increment
+-------+-----------+------+-----+---------+----------------+
1.2.(2)
LANGUAGE
// справочник языков
+----------+---------------------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+----------+---------------------+------+-----+---------+----------------+
il
tinyint(3) unsigned
language
char(32)
PRI
NULL
auto_increment
+----------+---------------------+------+-----+---------+----------------+
1.3
Autors and sourses
1.3.1.(3)
IAUTOR
// справочник (идентификатор) персоналий и
источников
+-------+------------------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+-------+------------------+------+-----+---------+----------------+
ia
int(10) unsigned
name1
char(128)
YES
PRI
NULL
name2
char(128)
YES
NULL
name3
char(128)
YES
year
smallint(6)
month
unsigned
NULL
auto_increment
NULL
YES
NULL
smallint(6) unsigned
YES
NULL
day
smallint(6)
YES
type
char(1)
unsigned
YES
NULL
NULL
+-------+------------------+------+-----+---------+----------------+
1.3.2.(4)
IA_EXT
// дополнительная таблица справочника
персоналий и источников
+-------------+------------------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+-------------+------------------+------+-----+---------+----------------+
last_upgr
timestamp(14)
YES
first_enter
timestamp(14)
YES
NULL
ia
int(10) unsigned
last_iu
int(10) unsigned
first_iu
int(10) unsigned
titul
varchar(128)
YES
NULL
biography
blob
YES
NULL
coordinate
varchar(128)
YES
NULL
NULL
PRI
NULL
auto_increment
0
0
+-------------+------------------+------+-----+---------+----------------+
43
1.3..3.(5)
TYPE_SOURSE // справочник типов источников
+-------+-----------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+-------+-----------+------+-----+---------+----------------+
itype
int(11)
type
char(128)
PRI
NULL
auto_increment
+-------+-----------+------+-----+---------+----------------+
1.4
Rubrics
1.4.1.(6)
IHEAD
// справочник (идентификатор) рубрик
+--------+------------------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+--------+------------------+------+-----+---------+----------------+
ih
int(10) unsigned
ihu
header
PRI
NULL
int(10) unsigned
auto_increment
0
char(128)
+--------+------------------+------+-----+---------+----------------+
2.
Regisration and privelege users
2.1.(7)
системы
IUSER
// основная информация о пользователе
(идентификатор)
+-----------+------------------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+-----------+------------------+------+-----+---------+----------------+
iu
int(10) unsigned
login
char(32)
passw
char(32)
privelege
tinyint(4)
PRI
NULL
auto_increment
0
+-----------+------------------+------+-----+---------+---------------2.2.(8)
IU_EXT
// дополнительная информация о
пользователе системы
+-------------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+-------------+------------------+------+-----+---------+-------+
last_upgr
timestamp(14)
YES
first_enter
timestamp(14)
YES
NULL
iu
int(10) unsigned
name
char(128)
YES
NULL
e_mail
char(128)
YES
NULL
quest
char(64)
YES
NULL
answer
char(64)
YES
NULL
subject
char(1)
YES
NULL
NULL
PRI
0
+-------------+------------------+------+-----+---------+-------+
2.3
Traffic and money
2.3.2.(9)
TRAFFIC
// учет трафика пользователя
+------------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+------------+------------------+------+-----+---------+-------+
time_enter
timestamp(14)
iu
int(10) unsigned
YES
NULL
byte
int(10) unsigned
YES
NULL
acquitt
char(0)
YES
NULL
PRI
0
+------------+------------------+------+-----+---------+-------+
44
2.3.1.(10)
MONEY
// учет оплаты трафика пользователем
+------------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+------------+------------------+------+-----+---------+-------+
time_enter
timestamp(14)
iu
int(10) unsigned
YES
NULL
sum
float(17,2)
YES
NULL
PS
char(128)
YES
NULL
PRI
0
+------------+------------------+------+-----+---------+-------+
3.
Documents
3.1.(11)
IDOC
// идентификаторы документа
+---------+---------------------+------+-----+---------+----------------+
Field
Type
Null
Key
Default
Extra
+---------+---------------------+------+-----+---------+----------------+
id
int(10) unsigned
il
PRI
NULL
tinyint(3) unsigned
auto_increment
0
name
char(127)
YES
NULL
keyword
char(255)
YES
NULL
access
tinyint(4) unsigned
100
+---------+---------------------+------+-----+---------+----------------+
3.2.(12)
ID_EXT
// дополнительная информация о документе
+-------------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+-------------+------------------+------+-----+---------+-------+
id
int(10) unsigned
last_upgr
timestamp(14)
YES
PRI
0
NULL
first_enter
timestamp(14)
YES
NULL
last_iu
int(10) unsigned
0
first_iu
int(10) unsigned
0
year
smallint(5) unsigned
YES
NULL
month
tinyint(2) unsigned
YES
NULL
day
tinyint(2) unsigned
YES
NULL
locate
varchar(127)
YES
NULL
PS
text
YES
NULL
+-------------+------------------+------+-----+---------+-------+
3.3.(14)
D_TXT
// основная БД документов
+----------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+----------+------------------+------+-----+---------+-------+
id
int(10) unsigned
pname1
varchar(127)
YES
pname2
varchar(127)
YES
abstract
blob
TXT
mediumblob
PRI
0
NULL
NULL
YES
NULL
YES
NULL
+----------+------------------+------+-----+---------+-------+
3.4.(15)
D_EXT
// приложения к БД документов
+-----------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+-----------+------------------+------+-----+---------+-------+
id_ext
id
int(10) unsigned
PRI
int(10) unsigned
NULL
auto_increment
0
gruffito
varchar(255)
YES
NULL
file_link
varchar(128)
YES
NULL
+-----------+------------------+------+-----+---------+-------+
45
3.5
Link-tables
3.5.1(16)
ID_IA
// таблица связи документа с авторами и источниками
+-------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+-------+------------------+------+-----+---------+-------+
id
int(10) unsigned
0
ia
int(10) unsigned
0
+-------+------------------+------+-----+---------+-------+
3.5.2(17)
ID_IH
// таблица связи документа с рубриками
+-------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+-------+------------------+------+-----+---------+-------+
id
int(10) unsigned
ih
int(10) unsigned
PRI
0
0
+-------+------------------+------+-----+---------+-------+
4.1
(18)
NEWS;
//новости
+-------------+------------------+------+-----+---------+-------+
Field
Type
Null
Key
Default
Extra
+-------------+------------------+------+-----+---------+-------+
id
int(10) unsigned
name
varchar(127)
first_enter
timestamp(14)
YES
locate
varchar(127)
YES
PRI
YES
0
NULL
NULL
NULL
ih
int(11)
YES
NULL
ia
int(11)
YES
NULL
name1
TXT
varchar(128)
mediumblob
YES
NULL
YES
NULL
+-------------+------------------+------+-----+---------+-------+
Такая организация БД позволяет по заголовкам документов (поле
“name” таблицы IDOC) и ключевым словам (поле “keyword”
таблицы IDOC) первым же запросом найти список ID-документов
удовлетворяющих
образцу.
ID
–
идентификационный
номер
присваиваемый документу при вводе методом автоинкремента
(прибавление следующей единицы (свойство MySQL)).
Полученный список позволяет быстро найти и сформировать все
элементы конечного документа, которые хранятся в разных
таблицах, каждая из которых содержит поле ID.
2.6.4. Отображение результатов поиска.
Шаблон
выходного
документа
представляет
собой
сложный
конгломерат кода на языке гипертекстовой развертки HTML,
интерпретатора PHP и языка запросов SQL. Результатом работы
46
этого кода является формирование в браузере пользователя
выходного документа (OUT_DOC.php)
47
2.6.5. Окно регистрации пользователя.
Представляет собой простейшую форму для ввода информации о
пользователе. Данные из формы передаются на сервер, где
обрабатываются скриптом и помещаются в таблицу IUSER для
последующей
идентификации
пользователя
и
разграничения
полномочий привилегий.
2.6.6. Конечный вывод документа.
Основная выходная форма единиц хранения в БД организована
следующим образом. Имеется HTML шаблон документа и PHP
скрипт организующий ряд SQL запросов к БД. Независимо от
способа доступа к конечному документу (через рубрикатор или в
результате поиска) выходная форма документа включает в себя
следующие
элементы,
хранящиеся
в
разных
таблицах
БД
объединенных общим полем «№ документа» - ID:
 Язык публикации
48
 Рубрика
 Аннотация
 Автор и/или источник
 Заголовок документа
 Собственно текст
 Авторская дата и место публикации
 Штамп (номер документа, дата, время внесения в БД).
 Приложения
2.6.7. Приложения.
Структура БД организована таким образом, что в основной таблице
БД D_TXT контент содержится в виде текста.
Все не текстовые материалы, как то: графические, аудио, видео и
другие материалы (бинарные, исполняемы файлы) хранятся в виде
простого файлового массива, организованного в виде дерева
каталогов, корнем которого является каталог DATA в котором в
49
начале каждого месяца автоматически создается подкаталог с
именем в формате: год_месяц. При попытке записи нового файла с
именем уже имеющемся в текущем каталоге, в нем создается
подкаталог с номером (именем) 1,2,3…
В БД существует таблица под названием D_EXT. В которой
хранятся
ссылки
на
каждый
внесенный
в
приложение
к
определенному файл. Таком образом в момент формирования
входного документа ниже основного текста выводится список
приложений с краткими комментариями и именами файлов. Причем
они (имена файлов) могут быть гиперссылками, если текущий
пользователь имеет соответствующие права, в противном случае,
пользователь видит простой текст.
50
2.6.8. Раздел сайта «Помощь».
Представляет собой краткую инструкцию для пользователя БД
имеющего квалификацию «Чайник».
51
2.6.9. Раздел сайта «ЧАВО».
Представляет собой ответы на часто задаваемые пользователями
вопросы.
52
2.6.10.Интерфейс редактора.
Интерфейс редактора БД предназначен для ввода и редактирования
документов, приложений к ним и справочных таблиц. Выбор
объекта редактирования организован посредством радиокнопок
(точек).
Справочные таблицы предназначены для хранения рубрикатора,
авторов и источников информации, а так же типов источников и
рубрик для регионов.
Кнопки «new» и «edit» запускают скрипты ввода нового или
соответственно
редактирования
документа
либо
строки
справочника.
Перед
редактированием
документа
для
его
идентификации
выводится форма поиска, позволяющая найти документ по номеру,
либо по одному или нескольким полям: название, заголовок,
автор/источник, рубрика, диапазон дат, номер или наименование. По
53
окончании
поиска
выдается
список
названий
найденных
документов, из которых можно выбрать нужный.
2.6.10.1. Интерфейс ввода и редактирования документа.
В форму для редактирования выводятся все имеющиеся в БД поля
относящиеся к данному документу, включая обязательные поля:
источник(и), рубрика(ки), название документа. При этом для полей
допускающих множественные значения, такие как авторы, рубрики,
выделяются все известные пункты.
Возможность вводить множественные значения для рубрик, авторов
и источников, позволяет базе приобрести многомерность (объем) в
отличие от плоских БД, где один документ принадлежит одному
источнику, одной рубрике, одному автору.
В форме для ввода и редактирования имеются следующие
функциональные
элементами
зоны,
сопровождающиеся
интерфейса
(полями
соответственными
ввода,
кнопками,
переключателями-галочками-боксами).
54
Функциональные зоны:
55
- поиск в рубриках
поиск в рубриках организован из-за того, что количество рубрик
достаточно велико, и ручной поиск замедляет ввод.
- язык публикации
выбор языка публикации организован в виде ниспадающего списка.
- выбор ключевых слов
производится из публикуемого текста по следующему алгоритму:
весь текст рассыпается в двумерный массив слов, вторым
измерением которого является количество повторений данного
слова в публикуемом тексте, то есть частотная характеристика.
Далее из этого массива исключаются слова, хранящиеся в таблице
исключений с учетом языка.
- таблица исключений
пополняется с помощью поля исключений и кнопки «Exclude».
- поле для служебного
56
не публикуется, а хранит комментарии для внутреннего пользования
редакторов.
- список приложений
можно изменить, если выбрать соответствующий переключатель и
нажать
кнопку
позволяет
«Record».
выключить
приложениям
для
в
Переключатель
интерфейсе
клиентов,
не
«платный
пользователя
имеющих
доступ»
доступ
к
соответствующих
привилегий.
2.6.10.2. Интерфейс ввода и редактирования приложений.
Имеет два поля для ввода:
1. Надпись или графити
2. Файл приложений, для выбора которого имеется кнопка
«обзор».
В режиме редактирования из списка приложений можно выбрать
приложения для внесения изменений. Переключатель «Вернуться»
57
позволяет
закольцевать
процесс
ввода
или
редактирования
приложений. Для записи сделанных изменений нужно нажать
кнопку «write».
58
2.6.11. Интерфейс администратора
Интерфейс администратора предназначен для управления БД,
распределения уровней доступа к данным, отслеживания трафика
клиентов получающих информацию на коммерческой основе.
К средствам администрирования относятся так же утилиты массовой
подготовки текстовой и бинарной информации к публикации
(обработчики, конверторы и пр.).
59
Раздел 3. Заключение.
Задача создания большой Базы Данных, доступной широкой
аудитории,
пополняемой
и
администрируемой
через
интерфейс,
рассчитанной
на
объем
1
не
менее
WEB
Терабайта
информации была поставлена и решена впервые в России.
Настоящий проект позволил в срок не более 6 месяцев осуществить
эту задачу. Стоимость проекта не превысила 5000$.
На данный момент База Данных содержит более 170 тысяч единиц
хранения, объемом 3,2 Гб. База Данных является публичной, т.е.
открытой.
Пополнение Базы Данных происходит двумя путями:
1. Крупные массивы информации конвертируются в формат
MySQL и закачиваются на сервер в центральном офисе.
2. Корреспонденты и редакторы вводят материалы, публикации,
сообщения и приложения к ним через WEB интерфейс в
режиме Online.
В перспективе (до конца года) реально достижение рубежа в 1
Терабайт и выход на посещаемость 30-100 тысяч посещений в сутки.
60
Список используемой литературы.
1. Дюбуа Поль. MySQL: Пер. с англ.: Уч. пос. – М.:
Издательский дом «Вильямс», 2001. – 816с.
2. Грег Холден, Николас Уэлс, Мэтью Келлер. Apache Server в
комментариях: Пер. с англ. – К.: Издательство «ДиаСофт»,
2000. – 480с.
3. Роберт Д. Шнайдер. Microsoft SQL Server. Проектирование
высокопроизводительных баз данных. Издательство «Лори»,
1998
4. Джефри
Л.
Бирн.
Microsoft
SQL
Server.
Руководство
администратора. Издательство «Лори», 1998
5. Будилов В.А. Практические занятия по PHP – СПб: Наука и
техника, 2001. – 352 стр. с ил.
6. Мартин
Грабер.
Справочное
руководство
по
SQL.
Издательство «Лори», 1998
7. Рассел Ч., Кроуфорд Ш. Unix и Linux: книга ответов – СПб:
ЗАО «Издательство «Питер», 1999. – 304 с.: ил.
8. Косентино К. PHP. WEB – профессионалам: Пер. с англ. – К.:
Издательская группа BHV, 2001. – 208 с.
9. Ивановский С.В. Unix: вопросы и ответы по Free BSD. – М:
Майор, 2001. – 160 с.
10. Водолазкий В.В. Путь к Linux. – М.: «Нолидж», 1999 – 368 с.,
ил.
11.Такет, Джек, Барнет, Стив. Использование Linux. Специальное
издание.: Пер. с англ. – 4-е изд. – К.: М.,: СПб.: Издательский
дом «Вильямс», 1999. – 704 с.: ил.
12. Мэтьюз Р.Д. и др. WEB-сервер под Unix. – Пер. с англ. – СПб:
Символ-Плюс, 1998 – 560 с.: ил.
61
13. Яргер Р., Риз Дж., Кинг Т. MySQL и mSQL. Базы данных для
небольших предприятий и Интернета – СПб: Символ-Плюс,
2000 – 560 с., ил.
62