ОГЛАВЛЕНИЕ
1. Сравнительный анализ традиционных и электронных способов коммерческой деятельности. 3
Интернет платежи. 4
Кредитные системы.. 5
Традиционная карточная платежная система. 6
Дебетовые системы.. 8
Цифровые наличные. 9
Техническое обеспечение систем электронной коммерции. 11
3/4 посетителей магазинов Рунета - россияне. 14
2. Функции СУБД.. 16
2.1. Непосредственное управление данными во внешней памяти. 16
2. 2. Управление буферами оперативной памяти. 16
2.3. Управление транзакциями. 17
2.4. Журнализация. 18
2.5. Поддержка языков БД.. 21
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ.. 23
1. Сравнительный анализ традиционных и электронных способов коммерческой деятельности
Общепризнанным является то, что сеть Интернет изменила лицо бизнеса. Всего за три года объем финансовых операций в общедоступных сетях, согласно исследованиям фирмы International Data Corp., стремительно взлетел с 50.4 миллионов долларов в 1997 году до прогнозируемых 1.3 триллиона долларов в 2003 году.
Компания IBM зарегистрировала понятие "электронный бизнес" как торговую марку. Звучит это так: "e-business (e'bis'nis) The transformation of key business processes through the use of Internet technologies" – "преобразование основных бизнес-процессов при помощи Интернет-технологий".
Имеется в виду, что все стороны деловых отношений, включая внутреннее планирование работы и управления, маркетинг, продажи, финансовый анализ, платежи, поиск сотрудников, поддержку клиентов и партнеров, перенесены в Интернет.
Надо заметить, что элементы электронного бизнеса существуют уже давно – многие компании десятилетиями применяют автоматические системы ведения бизнеса, такие, как, например, средства электронного обмена данными (Electronic Data Interchange, EDI), электронного перевода средств (Electronic Fund Transfer, EFT), планирования корпоративных ресурсов (Enterprise Resource Planning, ERP).
Сейчас же, когда к Интернету подключены десятки миллионов ПК, когда Интернет стал деловой средой, практически любая компания получила возможность ведения многих операций в режиме онлайн. Таким образом компании снижают издержки существующего бизнеса или переходят на совершенно новые бизнес-схемы.
Электронная коммерция - это составная часть электронного бизнеса, которая обеспечивает выполнение функций маркетинга, оформление заказов товаров и услуг, проведение платежей, выбор и реализацию схемы доставки товара, осуществление послепродажного обслуживания через Интернет.
Преимущества электронной коммерции по сравнению с традиционными видами коммерческой деятельности:
· Расширение рынков сбыта для поставщиков и новые возможности выбора для покупателей.
· Возможность для поставщика индивидуальной работы с покупателями, а для покупателей – персонально подобранные товары и услуги.
· Сокращение или устранение посреднической цепи, соответственно быстрый отклик.
· Сокращение издержек – интернет-магазины, имея склады, не требуют торговых залов, многочисленного обслуживающего персонала, снижаются затраты на рекламу, в конечном итоге - снижение цен для покупателей.
· Возможность непрерывного контроля за выполнением заказа.
· Новые возможности для бизнеса.
Недостатки:
Невозможность продажи некоторых видов товаров;
Низкое доверие покупателей;
Малая распространенность Интернет технологий у населения;
Малая распространенность безналичных расчетов;
Сложность с доставкой товара до конечного покупателя.
Интернет платежи
Основными субъектами электронной коммерции выступают Продавец, Банк Продавца, Покупатель, Банк Покупателя. При этом не вызывают вопросов такие традиционные способы оплаты заказанных в интернет-магазинах товаров, как:
Оплата наличными курьеру в момент доставки, либо в кассу магазина.
Оплата через отделение Сбербанка или почтовый перевод. Понятно, что при этом теряется одно из главных достоинств электронной коммерции — возможность купить, не выходя из дома.
Оплата со счета в банке. Корпоративному клиенту просто высылается счет с указанием всех реквизитов. Если банк имеет систему удаленного обслуживания "банк-клиент", то имеется возможность оплатить свою покупку прямо из дома или офиса.
Но существуют и специальные он-лайновые платежные системы, предназначенные для немедленного приема платежа через Интернет. Их можно разделить на три вида: кредитные, дебетовые и системы, работающие с цифровыми наличными.
Кредитные системы
Кредитные системы – это аналог обычных платежных систем с использованием кредитных карточек, только с с передачей данных через Интернет и, соответственно, с применением дополнительных мер безопасности (шифрование обмена сообщениями, цифровая подпись и т.д.).
В проведении платежей через Интернет с помощью кредитных карточек участвуют:
· Покупатель.
· Банк покупателя (банк-эмитент) - финансовая структура, которая выпустила кредитную карту для покупателя.
· Продавец.
· Банк продавца (банк-эквайер) - финансовая структура, занимающаяся обслуживанием операций продавца.
· Платежная система Интернет. Электронные компоненты, являющиеся посредниками между остальными участниками.
Традиционная карточная платежная система.
Процессинговый центр платежной системы. Организация, обеспечивающая информационное и технологическое взаимодействие между участниками традиционной платежной системы .
Расчетный банк платежной системы. Кредитная организация, осуществляющая взаиморасчеты между участниками платежной системы по поручению процессингового центра.
Схема проведения платежей в общем случае выглядит следующим образом:
Покупатель в электронном магазине формирует корзину товаров и выбирает способ оплаты "кредитная карта".
Реквизиты карты (номер, имя владельца, дата окончания действия) передаются платежной системе Интернет для дальнейшей авторизации. Это может быть сделано двумя способами:
· параметры карты вводятся непосредственно на сайте магазина, после чего они передаются платежной системе Интернет;
· непосредственно на сервере платежной системы.
Второй способ предпочтительнее, т.к. в этом случае сведения о карте не остаются в магазине, и, соответственно, снижается риск получения их третьими лицами или обмана продавцом. И в том, и в другом случае при передаче реквизитов кредитной карты все же существует возможность их перехвата в сети. Для предотвращения этого данные при передаче шифруются.
Платежная система Интернет передает запрос на авторизацию традиционной платежной системе.
Процессинговый центр платежной системы производит авторизацию карты.
Результат авторизации передается платежной системе Интернет.
Продавец и Покупатель получают результат авторизации.
При положительном результате авторизации:
· магазин оказывает услугу, или отгружает товар;
· процессинговый центр передает в расчетный банк сведения о совершенной транзакции. Деньги со счета покупателя в банке-эмитенте перечисляются через расчетный банк на счет магазина в банке-эквайере.
Естественный вопрос - насколько надежны такие платежи через Интернет?
Возникают следующие проблемы:
· возможность перехвата персональной и банковской информации время транзакции;
· возможность получения персональной и банковской информации из баз данных продавцов, банков;
· возможность использования данной информации в случае овладения ею.
Транзакция по кредитной карте через Интернет с точки зрения платежных систем сетей является "транзакцией без физического присутствия владельца", так называемой CNP-транзакцией, или MOTO - Mail Order Telephone Order. При этом с карты невозможно снять "slip", невозможно получить подпись владельца и сверить ее с подписью на карте, что открывает дополнительные возможности для мошенничества, в первую очередь - со стороны злоумышленников, имеющих в своем распоряжении номера чужих кредитных карт. Поскольку ущерб в результате мошеннических операций наносится истинному владельцу кредитной карточки, правила международных платёжных систем предоставляют владельцу карточки право оспорить факт совершения сделки и вернуть средства в течение определенного срока с момента совершения транзакции (chargeback - операция принудительного возврата компанией-эмитентом незаконно списанных средств на карточный счет клиента). Поскольку банк также не может брать на себя ответственность за риски такого рода, он будет стремиться к тому, чтобы иметь в той или иной форме гарантии получения опротестованных сумм от продавца. Продавец оказывается "крайним", потому что он несет все убытки. Надо заметить, правда, что аналогичные проблемы существуют и в обычных оффлайновых расчетах с помощью карт.
Основными недостатками кредитных систем, помимо уже упомянутых проблем безопасности транзакций, являются:
· существенные издержки на проведение транзакции, связанные с необходимостью проверки кредитоспособности клиента и авторизации карточки, и делающие их неприспособленными для микроплатежей;
· отсутствие анонимности.
Дебетовые системы
Дебетовые схемы платежей построены аналогично их оффлайновым прототипам: чековым и обычным наличным расчетам. Участниками расчетов являются эмитенты и пользователи. Под эмитентом понимается субъект, управляющий платежной системой. Он выпускает некие электронные единицы (цифровые эквиваленты денег на счетах в банках или бумажных чеков). Пользователи производят и принимают платежи через Интернет, используя выпущенные электронные единицы.
Электронные чеки (NetCash, NetChex, NetCheque) являются аналогом обычных бумажных чеков. Это предписания плательщика своему банку перечислить деньги со своего счета на счет получателя платежа. Чек содержит имя плательщика, название финансовой структуры, номер счета плательщика, название (имя) получателя платежа и сумму. Основная часть информации не кодируется. Операция происходит при предъявлении получателем чека в банке. Чек подписывается электронной подписью покупателя.
Схема платежей выглядит следующим образом:
· плательщик выписывает электронный чек, подписывает электронной подписью и пересылает его получателю;
· чек предъявляется к оплате платежной системе, происходит проверка электронной подписи;
· в случае подтверждения ее подлинности поставляется товар или оказывается услуга;
· со счета плательщика деньги перечисляются на счет получателя.
· Схема проста, но для России пока неактуальна, т.к. отсутствует широкая практика использования чеков даже при оффлайновых расчетах.
Цифровые наличные
Цифровые наличные полностью моделируют реальные деньги. Эмитент выпускает их электронные аналоги (набор цифр, подписанный электронной подписью эмитента), покупатель заранее обменивает реальные деньги на цифровые (открыв счет в банке системы), далее они используются при покупках, а затем продавец погашает их у эмитента.
Существует два типа цифровых наличных:
· на компьютере клиента (в качестве примеров можно привести eCash, из российских - WebMoney, PayCash);.
· на смарт-картах (Mondex).
Схема платежей такова:
· клиенты загружают соответствующее программное обеспечение и активизируют свои электронные "кошельки";
· покупатель перечисляет на сервер продавца электронные деньги за покупку;
· деньги предъявляются эмитенту, который проверяет их подлинность;
· в случае подлинности электронных купюр счет продавца увеличивается на сумму покупки, а покупателю отгружается товар или оказывается услуга;
· электронные деньги впоследствии можно конвертировать в реальные деньги.
Вся передача цифровой наличности идет по Интернет вне банковских сетей, между самими продавцами и продавцами. Однако, в отличие от CyberCash, для проведения расчетов необходимо открытие счета в каком-либо конкретном банке. Эмитировать электронные наличные могут как банки, так и небанковские организации. Однако, до сих пор не выработана единая система конвертирования разных видов электронных денег. Поэтому только сами эмитенты могут гасить выпущенную ими электронную наличность. Кроме того, использование подобных денег от нефинансовых структур не обеспечено гарантиями со стороны государства. Однако, малая стоимость транзакции делает электронную наличность привлекательным инструментом платежей в Интернет.
В качестве основных преимуществ подобных систем можно выделить следующее:
· системы подходят для микроплатежей, это связано с тем, что номинал купюр может быть любым;
· стоимость транзакции с использованием электронных денег, их обработка и учёт значительно дешевле стоимости обработки реальных денег, кредитных карт, чеков и других средств платежа;
· может быть обеспечена анонимность, так как при их использовании не требуют удостоверения личности плательщика и его кредитоспособности.
К негативным сторонам может быть отнесено:
· необходимость предварительной покупки купюр;
· отсутствие возможности предоставления кредита.
Смарт-карты - это пластиковые карты, которые имеют встроенный микропроцессор. Смарт-карта выпускается (эмитируется) банком и на нее записывается величина суммы денег, которые покупатель разместил в своем банке. Кроме этого карта содержит идентификаторы эмитента и покупателя, номер счета покупателя и др. служебную информацию. При этой схеме деньги покупателя хранятся в банке, на так называемом карт-счете и списываются банком по мере расходования их владельцем с перечислением их на счет торговой точки. Соответствующая отметка производится и в смарт-карте во время совершения операции купли-продажи. Карта может пополняться (кредитоваться) в банке эмитенте, при этом на карт-счет владельца заносится соответствующая сумма, которая списывается с его обычного счета в банке, либо поступает от владельца в виде наличных денег. Карта может использоваться как для платежей через Интернет, так и через автономные принимающие устройства. Основными преимуществами этого вида пластиковых карточек является повышенная надёжность, безопасность, многофункциональные возможности, ведение на одной карточке нескольких счетов. Существенным недостатком смарт-карт является их высокая себестоимость по сравнению с обычными картами.
Наиболее известными платёжными системами, использующими в России смарт-карты, являются:
· АС Сберкарт;
· "Золотая Корона".
Техническое обеспечение систем электронной коммерции
В чем заключается специфика сайта электронной коммерции? Для электронной торговли необходимо, чтобы информация была доступна 24 часа 7 дней в неделю. Каталог и витрина должны быть не просто статичной вывеской, а должны легко изменяться менеджером (без обращения к программистам и Web-дизайнерам). Система электронной коммерции должна иметь способность обрабатывать большое количество заказов, и при этом интегрироваться в существующие системы управления предприятием. В системах класса В2В нужны мощные и удобные средства поиска, так как обычно в таких системах очень много каталогов товаров. Нужно иметь систему разграничения доступа клиентов, обеспечить конфиденциальность и защиту данных при помощи паролей и шифрования. Поэтому при построении сети центров электронной торговли, в которой будут циркулировать данные деловых партнеров, необходимо обеспечить самый серьезный уровень защиты.
В принципе, любой Web-сайт состоит из набора страниц, а различия заключаются лишь в том, как они организованы. Существует два вида организации Web-сайта – статический и динамический. В первом случае создается в HTML-форме каждая в отдельности страница, включая ее оформление и контент. Во втором – в основе любой Web-страницы лежит шаблон, определяющий расположение в окне Web-браузера всех компонентов страницы и вставка конкретной информации производится с использованием стандартных средств, не требующих знания языка HTML. Контент динамических сайтов хранится обычно в базе данных, а на некоторых языках программирования пишутся программы, генерирующие из содержимого таких баз HTML-странички, которые, собственно, и показываются пользователю. Существует несколько общепризнанных языков и систем программирования для разработки этих сайтов - Perl , ASP, PHP (язык, специально разработанный для написания динамических страниц, есть версии PHP3 практически под все виды Unix и Win32). Если возможности PHP недостаточны, следующий вариант mod_perl (механизм, позволяющий пользоваться всеми средствами языка Perl в среде сервера Apache, в частности, писать программы на CGI и модули на Perl, встраивать Perl-код в страницы сайта, использовать Perl в файлах конфигурации и управлять работой сервера средствами этого языка).
Следует учесть, что динамически генерируемые Web-страницы имеют два основных недостатка:
· могут возникнуть проблемы с индексацией роботами поисковых систем;
· возрастает нагрузка на сервер при определенной интенсивности запросов.
Преимущества динамической организации сайта электронной коммерции являются очевидными, а программный комплекс управления таким сайтом становится частным случаем системы управления веб-контентом. Стандартная структура сайта электронной коммерции:
Первый блок – фронт-офис, это то, что видит покупатель в интернет-магазине – витрину, каталог, описание товаров, систему оформления заказов, информацию о магазине и т.д.
Второй блок – бэк-офис, это то, что видит менеджер интернет-магазина. Через бэк-офис менеджер управляет магазином, он может редактировать базу данных товаров; он может сконфигурировать каталог товаров; он устанавливает цены и скидки на товары; он задает различные дисконтные схемы для своих дилеров и/или постоянных покупателей; он также управляет складом товаров интернет-магазина. Кроме того, он может сформировать заказы на пополнение склада интернет-магазина и получать всевозможную статистику о всех заказах, товарах и покупателей в интернет-магазине.
Третий блок – это сама база данных, в которой хранится вся информация о товарах, покупателях, заказах.
С точки зрения программного обеспечения минимум компонентов, необходимых для функционирования интернет-магазина, включает в себя:
Web-сервер - распределяет поступающие запросы, производит разграничение доступа. Безусловным лидером здесь является Apache, следующие по распространенности - Microsoft-IIS и Netscape-Enterprise.
Сервер приложений - управляет работой всей системы, в частности бизнес-логикой интернет-магазина (каталог товаров, корзина покупателя, система оплаты, система заказов, клиентская часть - это контроль заказов, оплаты).
СУБД - осуществляет хранение и обработку данных о товарах, клиентах, счетах и т.п. Коммерческие СУБД, как правило, слишком велики и слишком дороги для большинства веб-проектов малого и среднего уровня. Широко распространены условно бесплатные СУБД MySQL, PostgreSQL. Решение для крупного бизнеса - ORACLE, MS SQL.
К этому комплексу подключаются платежные системы, для полной интеграции с бизнес-процессами компании может быть организован шлюз для электронной передачи данных между интернет-магазином и внутренней системой автоматизации документооборота.
3/4 посетителей магазинов Рунета - россияне
Среди посетителей российских интернет-магазинов значительно больше россиян, чем в аудитории Рунета в целом. Если в целом на русскоязычных ресурсах 2/3 хитов совершается российскими пользователями, то на сайтах интернет-магазинов российская аудитория дает более 3/4 трафика, говорится в отчете, составленном компанией SpyLog. Преобладание российских пользователей неудивительно, если принять во внимание, что в выборку были включены магазины, ориентированные в первую очередь на российский рынок. Данное ограничение особенно заметно сказалось на доле аудитории из стран СНГ и Прибалтики - в секторе онлайновой торговли доля ближнего зарубежья не превышает 6% против 14% в целом по Рунету (данные по хитам). Русскоязычную аудиторию из бывших республик СССР отличает и крайне низкая активность на сайтах интернет-магазинов - в среднем за день на каждого посетителя из Украины или Прибалтики приходится около 3 хитов против 4,5 хитов для российских посетителей и 5-6 хитов для посетителей из стран дальнего зарубежья. Это позволяет говорить о том, что среди посетителей из ближнего зарубежья (несмотря на немногочисленность данной категории) преобладают случайные посетители. Помимо России, только у одной страны - Израиля - доля в аудитории интернет-магазинов (2,1% по хитам) выше, чем в целом по Рунету (1,8%). Очевидно, что подобный результат достигается за счет интереса русской диаспоры (а ее доля в населении максимальна именно в Израиле) к книгам, музыке и видео из России, которые можно заказать через интернет. В аудитории соответствующих магазинов доля "стран диаспоры" составляет 18%, в т.ч. США - 11,6%, Израиля - 4,3%, Германии - 2,1%. В то же время в аудитории магазинов другого профиля (компьютерная техника, сотовые телефоны, продукты и т.д.) доля "стран диаспоры" составляет лишь 3-3,5%. В противоположном направлении изменяется процент российских пользователей - 67% в книжных магазинах, магазинах музыки и видео и около 85% в прочих магазинах.
2. Функции СУБД
К числу функций СУБД принято относить следующие:
2.1. Непосредственное управление данными во внешней памяти
Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. Но подчеркнем, что в развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, и если использует, то как организованы файлы. В частности, СУБД поддерживает собственную систему именования объектов БД.
2. 2. Управление буферами оперативной памяти
СУБД обычно работают с БД значительного размера; по крайней мере этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов.
Заметим, что существует отдельное направление СУБД, которое ориентировано на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований.
2.3. Управление транзакциями
Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.
То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (на самом деле, это несколько идеализированное представление, поскольку в некоторых случаях пользователи многопользовательских СУБД могут ощутить присутствие своих коллег).
С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).
Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД. При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериализации необходимо выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей.
2.4. Журнализация
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.
Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода.
Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).
При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно мы рассмотрим это в соответствующей лекции.
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.
2.5. Поддержка языков БД
Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. Мы рассмотрим более подробно языки ранних СУБД в следующей лекции.
В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). В нескольких лекциях этого курса язык SQL будет рассматриваться достаточно подробно, а пока мы перечислим основные функции реляционной СУБД, поддерживаемые на "языковом" уровне (т.е. функции, поддерживаемые при реализации интерфейса SQL).
Прежде всего, язык SQL сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.
Язык SQL содержит специальные средства определения ограничений целостности БД. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности БД производится на языковом уровне, т.е. при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код.
Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне.
Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. Докучаев А.А., Мошенский С.А., Назаров О.В. Средства информатики в офисе торговой фирмы. Средства компьютерных коммуникаций. – СП б, ТЭИ, 1996. – 32с.
2. Имери В. Как сделать бизнес в Internet. – М.: Экономика, 1997. – 256с.
3. Пятибратов А.П., Гудындо Л.П., Кириченко А.А. Вычислительные системы, сети и телекоммуникации. – М., Финансы и статистика, 1998.
4. Нанс Б. Компьютерные сети: Пер. с англ. – М.: Восточная книжная компания, 1996.
5. Шатт С. Мир компьютерных сетей: Пер. с англ. – Киев: BHV, 1996.
6. Клименко С.В., Уразметов В.Ф. Internet: среда обитания информационного общества. Протвино.: РЦ ФТИ, 1995.