Зміст
1. Архітектура "клієнт-сервер"
1.1. Відкриті системи
1.2. Клієнти і сервери локальних мереж
1.3. Системна архітектура "клієнт-сервер"
1.4. Сервери баз даних
1.5. Принципи взаємодії між клієнтськими
і серверними частинами
1.6. Переваги протоколів віддаленого виклику
процедур
1.7. Типове розділення функцій між клієнтами
і серверами
1.8. Архітектури процесора бази даних

2. Трирівнева архітектура "клієнт-сервер"

3. Програмні засоби розробки
3.1. Універсальні засоби
3.2. Персональні СУБД

4. Intranet та архітектура "клієнт-сервер".
4.1. Дворівнева архітектура "клієнт-сервер"
4.2. Трирівнева архітектура "клієнт-сервер"
4.2.1. Програми розширення серверної частини

5. Приклад бази даних


1. Архітектура "клієнт-сервер"
Стосовно до систем баз даних архітектура "клієнт-сервер" цікава і актуальна головним чином тому, що забезпечує просте і відносно дешеве рішення проблеми колективного доступу до баз даних в локальній мережі.

1.1. Відкриті системи
Реальне розповсюдження архітектури "клієнт-сервер" стало можливим завдяки розвитку і широкого впровадження в практику концепції відкритих систем. Тому ми почнемо з короткого вступу до відкриті системи.

Основним сенсом підходу відкритих систем є спрощення комплексування обчислювальних систем за рахунок міжнародної та національної стандартизації апаратних і програмних інтерфейсів. Головною спонукальної причиною розвитку концепції відкритих систем з'явилися повсюдний перехід до використання локальних комп'ютерних мереж і ті проблеми комплексування апаратно-програмних засобів, які викликав цей перехід. У зв'язку з бурхливим розвитком технологій глобальних комунікацій відкриті системи набувають ще більшого значення і масштабність.

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

Практичної опорою системних і прикладних програмних засобів відкритих систем є стандартизована операційна система. В даний час такою системою є UNIX. Фірмам-постачальникам різних варіантів ОС UNIX в результаті тривалої роботи вдалося прийти до угоди про основні стандарти цієї операційної системи. Зараз всі поширені версії UNIX в основному сумісні по частині інтерфейсів, що надаються прикладним (а в більшості випадків і системним) програмістам. Як здається, незважаючи на появу що претендує на стандарт системи Windows NT, саме UNIX залишиться основою відкритих систем у найближчі роки.

Технології та стандарти відкритих систем забезпечують реальну і перевірену практикою можливість виробництва системних і прикладних програмних засобів з властивостями мобільності (portability) і інтероперабельності (interoperability). Властивість мобільності означає порівняльну простоту перенесення програмної системи в широкому спектрі апаратно-програмних засобів, які відповідають стандартам. Інтероперабельность означає спрощення комплексування нових програмних систем на основі використання готових компонентів зі стандартними інтерфейсами.

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

1.2. Клієнти і сервери локальних мереж
В основі широкого розповсюдження локальних мереж комп'ютерів лежить відома ідея поділу ресурсів. Висока пропускна здатність локальних мереж забезпечує ефективний доступ з одного вузла локальної мережі до ресурсів, що знаходяться в інших вузлах.

Розвиток цієї ідеї призводить до функціонального виділення компонентів мережі: розумно мати не тільки доступ до ресурсами віддаленого комп'ютера, але також одержувати від цього комп'ютера деякий сервіс, який специфічний для ресурсів даного роду і програмні засоби. Так ми приходимо до розрізнення робочих станцій і серверів локальної мережі.

Робоча станція призначена для безпосередньої роботи користувача або категорії користувачів і володіє ресурсами, що відповідають локальним потребам даного користувача.

Сервер локальної мережі повинен володіти ресурсами, що відповідають його функціональному призначенню і потребам мережі. Зауважимо, що у зв'язку з орієнтацією на підхід відкритих систем, правильніше говорити про логічних серверах (маючи на увазі набір ресурсів і програмних засобів, що забезпечують послуги над цими ресурсами), які розташовуються не обов'язково на різних комп'ютерах. Особливістю логічного сервера у відкритій системі є те, що якщо з міркувань ефективності сервер доцільно перемістити на окремий комп'ютер, то це можна зробити без потреби в будь-якій переробці як його самого, так і використовують його прикладних програм.

Прикладами сервером можуть служити:
• сервер телекомунікацій, що забезпечує послуги по зв'язку даної локальної мережі з зовнішнім світом;
• обчислювальний сервер, що дає можливість виробляти обчислення, які неможливо виконати на робочих станціях;
• дисковий сервер, що володіє розширеними ресурсами зовнішньої пам'яті і надає їх у використання робочим станціями і, можливо, інших серверів;
• файловий сервер, що підтримує загальне сховище файлів для всіх робочих станцій;
• сервер баз даних фактично звичайна СУБД, що приймає запити по локальній мережі і повертає результати.

Сервер локальної мережі надає ресурси (послуги) робочих станцій і/або інших серверів.

Прийнято називати клієнтом локальної мережі, запитувач послуги у деякого сервера і сервером - компонент локальної мережі, що надає послуги деяким клієнтам.

1.3. Системна архітектура "клієнт-сервер"
Зрозуміло, що в загальному випадку, щоб прикладна програма, що виконується на робочій станції, могла запросити послугу у деякого сервера, як мінімум потрібно деякий інтерфейсний програмний шар, який підтримує такого роду взаємодія (було б щонайменше неприродно вимагати, щоб прикладна програма безпосередньо користувалася примітивами транспортного рівня локальної мережі). З цього, власне, і випливають основні принципи системної архітектури "клієнт-сервер".

Система розбивається на дві частини, які можуть виконуватися в різних вузлах мережі, - клієнтську та серверну частини. Прикладна програма або кінцевий користувач взаємодіють з клієнтською частиною системи, яка в простому випадку забезпечує просто надсетевой інтерфейс. Клієнтська частина системи при потребі звертається по мережі до серверної частини. Зауважимо, що в розвинених системах мережеве звернення до серверної частини може і не знадобитися, якщо система може передбачати потреби користувача, і в клієнтської частини містяться дані, здатні задовольнити його наступний запит.

Інтерфейс серверної частини визначений і фіксований. Тому можливе створення нових клієнтських частин існуючої системи (приклад інтероперабельності на системному рівні).

Основною проблемою систем, заснованих на архітектурі "клієнт-сервер", є те, що відповідно до концепції відкритих систем від них вимагається мобільність в якомога більш широкому класі апаратно-програмних рішень відкритих систем. Навіть якщо обмежитися UNIX-орієнтованими локальними мережами, в різних мережах застосовується різна апаратура та протоколи зв'язку. Спроби створення систем, що підтримують всі можливі протоколи, призводить до їх перевантаження мережевими деталями на шкоду функціональності.

Ще більш складний аспект цієї проблеми пов'язаний з можливістю використання різних представлень даних в різних вузлах неоднорідною локальної мережі. У різних комп'ютерах може існувати різна адресація, представлення чисел, кодування символів і т.д. Це особливо важливо для серверів високого рівня: телекомунікаційних, обчислювальних, баз даних.

Спільним рішенням проблеми мобільності систем, заснованих на архітектурі "клієнт-сервер" є опора на програмні пакети, що реалізують протоколи віддаленого виклику процедур (RPC - Remote Procedure Call). При використанні таких коштів звернення до сервісу у віддаленому вузлі виглядає як звичайний виклик процедури. Засоби RPC, в яких, природно, міститься вся інформація про специфіку апаратури локальної мережі та мережевих протоколів, переводить виклик в послідовність мережевих взаємодій. Тим самим, специфіка мережного середовища і протоколів прихована від прикладного програміста.

При виклику віддаленої процедури програми RPC виробляють перетворення форматів даних клієнта в проміжні машинно-незалежні формати і потім перетворення в формати даних сервера. При передачі відповідних параметрів проводяться аналогічні перетворення.

Якщо система реалізована на основі стандартного пакету RPC, вона може бути легко перенесена в будь-яку відкриту середу.

Технологія "клієнт-сервер" стосовно до СУБД зводиться до поділу системи на дві частини - програму-клієнт (front-end) і сервер бази даних (back-end). Ця архітектура поєднує кращі риси обробки даних на мейнфреймах та технології "файл-сервер". Від мейнфреймів технологія "клієнт-сервер" запозичила такі риси, як централізоване адміністрування, безпека, надійність. Від технології "файл-сервер" успадковані низька вартість та можливість розподіленої обробки даних, використовуючи ресурси комп'ютерів-клієнтів. Зараз графічний інтерфейс користувача став стандартом для систем "клієнт-сервер". Крім того, архітектура "клієнт-сервер" значно спрощує і прискорює розробку додатків за рахунок того, що правила перевірки цілісності даних знаходяться на сервері. Неправильно працює клієнтська програма не може привести до втрати чи спотворення даних. Всі ці можливості, раніше властиві тільки складним і дорогим системам, зараз доступні навіть невеликим організаціям. Вартість обладнання, програмного забезпечення і обслуговування для персональних комп'ютерів в десятки разів нижче, ніж для мейнфреймів.
Особливості обробки даних в різних архітектурах показані на рис.1.


Рис.1. Обробка даних в різних архітектурах

Локальний комп'ютер

Локальне додаток


СУБД



Дані

Архітектура "файл-сервер"

Клієнт
Файл-сервер
Мережеве додаток
Дані

СУБД


Клієнт

пересилання Мережеве додаток
 даних

СУБД

Архітектура "клієнт-сервер"


 Сервер БД
Клієнтське
СУБД додаток


Дані

Клієнтський додаток
пересилання запитів
і результатів

1.4. Сервери баз даних
Термін "сервер баз даних" зазвичай використовують для позначення всієї СУБД, заснованої на архітектурі "клієнт-сервер", включаючи і серверну, і клієнтську частини. Такі системи призначені для зберігання і забезпечення доступу до баз даних.

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

1.5. Принципи взаємодії між клієнтськими і серверними частинами
Доступ до бази даних від прикладної програми або користувача виробляється шляхом звернення до клієнтської частини системи. В якості основного інтерфейсу між клієнтської і серверної частинами виступає мова баз даних SQL.

Це мова по суті справи представляє собою поточний стандарт інтерфейсу СУБД у відкритих системах. Збірна назва SQL-сервер відноситься до всіх серверів баз даних, заснованих на SQL.

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

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

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

1.6. Переваги протоколів віддаленого виклику процедур
Згадувані вище протоколи віддаленого виклику процедур особливо важливі в системах управління базами даних, заснованих на архітектурі "клієнт-сервер".

По-перше, використання механізму віддалених процедур дозволяє дійсно перерозподіляти функції між клієнтської і серверної частинами системи, оскільки в тексті програми віддалений виклик процедури нічим не відрізняється від віддаленого виклику, і отже, теоретично будь-який компонент системи може розташовуватися і на стороні сервера, і на стороні клієнта.

По-друге, механізм віддаленого виклику приховує відмінності між взаємодіючими комп'ютерами. Фізично неоднорідна локальна мережа комп'ютерів приводиться до логічно однорідної мережі взаємодіючих програмних компонентів. В результаті користувачі не зобов'язані серйозно піклуватися про разову закупівлю сумісних серверів і робочих станцій.

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

У деяких випадках хотілося б включити до складу клієнтської частини системи деякі функції для роботи з "локальним кешем" бази даних, тобто з тією її частиною, яка інтенсивно використовується клієнтської прикладною програмою. У сучасній технології це можна зробити тільки шляхом формального створення на стороні клієнта локальної копії сервера бази даних і розгляду всієї системи як набору взаємодіючих серверів.

З іншого боку, іноді хотілося б перенести більшу частину прикладної системи на сторону сервера, якщо різниця в потужності клієнтських робочих станцій і сервера надто велика. В общем-то при використанні RPC це зробити неважко. Але потрібно, щоб базове програмне забезпечення серверу дійсно дозволяло це. Зокрема, при використанні ОС UNIX проблеми практично не виникають.

1.8. Архітектури процесора бази даних.
Основна частина будь-якої системи "клієнт-сервер" - це сервер БД. З часу виникнення архітектури "клієнт-сервер" з'явилося багато варіантів архітектури процесора БД, оскільки він багато в чому визначає успіх всієї системи. Основна вимога до сервера БД - забезпечення мінімального часу виконання запитів при максимально можливому числі користувачів. Існують дві основні архітектури для побудови процесора БД: архітектура з декількома процесами і багатопотокова архітектура.

1. Архітектура з декількома процесами
Характеризується тим, що кілька примірників виконавчого файлу працюють одночасно. Ці системи відрізняються гарною масштабованість??, Але вимагають значних витрат пам'яті, тому що пам'ять кожному екземпляру програми виділяється окремо. Ця архітектура має на увазі наявність ефективного механізму взаємодії процесів і покладається на операційну систему при поділі процесорного часу між окремими екземплярами програми. Найвідоміший приклад сервера, побудованого за даної архітектури, - Oracle Server. Коли користувач підключається до БД Oracle, він насправді запускає окремий екземпляр виконавчого файлу процесора бази даних.
2. Багаторівнева архітектура
Ця архітектура використовує тільки один файл, з декількома потоками виконання. Головна перевага - більш скромні вимоги до обладнання, ніж для архітектури з декількома процесами. Тут сервер бере на себе розподіл часу між окремими потоками, іноді даючи перевагу деяким завданням над іншими. Крім того, відпадає необхідність у складному механізмі взаємодії процесів. З цієї архітектурі побудовані MS SQL Server та Sybase SQL Server.

2. Трирівнева архітектура "клієнт-сервер"
На верхньому рівні абстрагування взаємодії клієнта і сервера досить чітко можна виділити наступні компоненти:

• презентаційна логіка (Presentation Layer - PL), призначена для роботи з даними користувача;
• бізнес-логіка (Business Layer - BL), призначена для перевірки правильності даних, підтримки посилальної цілісності ..;
• логіка доступу до ресурсів (Access Layer - AL), призначена для зберігання даних;

Таким чином можна, можна прийти до декількох моделях клієнт-серверного взаємодії:

1. "Товстий" клієнт. (fat client)

Сервер БД для користувача інтерфейс

Дані Бізнес-логіка




Інтерфейс користувача

Бізнес-логіка

Найбільш часто зустрічається варіант реалізації архітектури клієнт-сервер у вже впроваджених і активно використовуваних системах. Така модель має на увазі об'єднання в клієнтському додатку як PL, так і BL, таким чином забезпечується повна децентралізація управління бізнес-логікою. Однак у випадку необхідності виконання будь-яких змін у клієнтському додатку доведеться змінювати вихідний код. Серверна частина, при описаному підході, являє собою сервер баз даних, що реалізує AL. До описаної моделі часто застосовують абревіатуру RDA - Remote Data Access.

2. "Тонкий" клієнт. (thin client)


 Бізнес-
Логіка для користувача інтерфейс



Дані


Інтерфейс користувача

Модель, що починає активно використовуватися в корпоративному середовищі у зв'язку з розповсюдженням Internet-технологій і, в першу чергу, Web-браузерів. У цьому випадку клієнтський додаток забезпечує реалізацію PL, тому клієнт може задовольнятися досить скромною апаратною платформою, а сервер об'єднує BL і AL. Максимальне завантаження сервера передбачає виконання бізнес-логіки тільки за допомогою збережених процедур сервера (Збережені процедури - відкомпілювалися SQL-інструкції, що зберігаються на сервері). Це дозволяє максимально централізувати контроль над даними і легко змінювати правила роботи відразу для цілого підприємства. З іншого боку, незначна коректування правил, що стосується тільки частини користувачів, що потребують тривалої процедури узгодження. У цьому випадку неможливо реалізувати якісь винятки із загальних правил для деяких користувачів або програм. У принципі, це добре і є запорукою безпеки та цілісності даних.

3. Сервер бізнес-логіки. (трирівнева архітектура)

 Проміжний сервер
Користувацький
Бізнес-логіка інтерфейс
другого рівня



 Сервер БД
Користувацький
Бізнес-логіка інтерфейс
сервера



Дані

Модель з фізично виділеним в окремий додаток блоком BL, таким чином отримуємо трирівневу архітектуру "клієнт-сервер". На сервері БД може функціонувати "універсальна" частина бізнес-логіки (правила на рівні підприємства чи групи пов'язаних додатків). Така схема дозволяє підтримувати тонких клієнтів на користувацьких комп'ютерах і в той же час розвантажити сервер БД від надмірної завантаження при збереженні гнучкої системи роботи з бізнес-правилами. В якості проміжного сервера може використовуватися другу SQL-сервер, але частіше раціональніше задіяти персональну СУБД, яка менш вимоглива до апаратних ресурсів і може забезпечити зручні засоби побудови та підтримки бізнес-логіки.

3. Програмні засоби розробки

3.1. Універсальні засоби
Для розробки клієнтських додатків існує величезне число універсальних пакетів програм, які дозволяють виконати з'єднання з сервером і розробити для користувача зручний графічний інтерфейс, що дозволяє ефективно працювати з даними. Деякі з цих коштів для розробки додатків в архітектурі "клієнт-сервер" перераховані в таблиці.

Найменування Коротка характеристика
CA-OpenROAD Повнофункціональна об'єктно-орієнтоване середовище для розробки додатків на основі мови четвертого покоління 4GL.
Delphi Client/Server Універсальний пакет для розробки клієнтських додатків. Забезпечує об'єктно-орієнтовану розробку з використанням візуальних засобів. Підтримує групову роботу над програмою.
Magic 6.0 таблично-керований інструментарій для розробки трирівневих програм "клієнт-сервер".
MS Visual Basic 5.0 Універсальний пакет розробки користувацьких додатків. Забезпечує візуальне побудова форм і компіляцію програми. У повному обсязі підтримуються OLE 2.0 та OLE Automation. Для роботи з даними призначений візуальний інструментарій Visual Database Tools.
PowerBuilder 4.0 Об'єктно-орієнтоване засіб розробки програм "клієнт-сервер". Має потужні візуальні засоби; підтримує стандарти OLE і ODBC.
Progress 8 Пакет підтримує компонентну об'єктно-орієнтовану розробку програм. Використовується нова технологія SmartObject і середу компонентів програми (ACE).
SAS System Забезпечує інструментарій для доступу, управління, аналізу та подання даних в додатку для величезної кількості систем та комп'ютерних платформ, включаючи мейнфрейми. Має 35 видів інтерфейсу для різних систем і мова програмування четвертого покоління. Підтримки ODBC.
Uniface Six Незалежна середовище розробки. Підтримки управління на рівні моделі та компонентні програмування. Має потужні візуальні засоби. Допускає групову розробку. Має інтерфейс до більш ніж 30 серверів БД на різних платформах.


3.2. Персональні СУБД.
Для розробки клієнтських додатків в більшості випадків замість універсальних засобів розробки зручніше використовувати персональні СУБД. Використання персональних СУБД дозволяє не тільки ефективно організовувати роботу з бізнес-правил, а й підтримати незалежну роботу клієнтського додатку за рахунок наявності власних форматів зберігання даних. Коротка характеристика деяких персональних СУБД наведена в таблиці.

Найменування Коротка характеристика
Lotus Approach 97 Дозволяє виконувати всі види обробки даних. Має дуже простий інтерфейс. СУБД тісно інтегрована з базами даних Notes і електронних таблиць Lotus 1-2-3. Підтримує технологію електронного обміну повідомленнями MAPI.
MS Access 97 Повнофункціональна СУБД, що володіє багатим набором візуальних засобів, численними майстрами і потужним мовою програмування Visual Basic for Applications. Має гнучку систему підготовки звітів. Підтримуються технології ODBC і OLE 2.0. СУБД тісно інтегрована з усіма додатками MS Office.
MS Visual FoxPro 5 Одна з найбільш швидких персональних СУБД, що поєднує технологію xBase і об'єктно-орієнтована мова програмування. Має великий набір візуальних засобів розробки і майстрів для швидкої побудови додатків і звітів. Підтримуються технології ActiveX, ODBC і OLE 2.0. Дозволяє створювати OLE-сервера і має дуже розвинені засоби розробки і підтримки програм "клієнт-сервер".
Paradox 7 Підтримує всі види роботи з даними. Для візуального виконання стандартних завдань є спеціальний засіб Experts. Наділений власним досить складною мовою ObjectPAL. Підтримує технології OLE 2.0, ActiveX, MAPI та ODBC.



4. Intranet та архітектура "клієнт-сервер".
4.1. Дворівнева архітектура "клієнт-сервер"



Web-броузер Джерело даних



Web-сервер




NOS (Network Operation System)

Розмежування функцій між Web-браузером і Web-сервером є дуже чітким. Web-сервер надає HTML-сторінки, а броузер відображає ці сторінки шляхом інтерпретації тегів HTML.


4.2. Трирівнева архітектура "клієнт-сервер"



Web-броузер Джерело даних


Третій рівень
Програма
розширення
сервера

HTML
Web-сервер




NOS

Клієнтський рівень займає броузер, на рівні сервера знаходиться сервер БД, а на проміжному рівні розташовуються Web-сервер та програма розширення сервера. Таке архітектурне рішення дозволяє зменшити мережевий трафік, робить компоненти взаємозамінними і підвищує рівень безпеки. Однак така архітектура також ускладнює обробку транзакцій БД через природи протоколу HTTP, не запам'ятовуючого стану (цей протокол використовує для передачі даних між браузером і сервером БД).
Броузер посилає Web-серверу запити на доставку Web-сторінок або даних. Web-сервер обслуговує заявки на Web-сторінки, а запити відправляє програмі-розширенню серверної частини. Остання приймає передані їй запити, перетворює їх у форму, зрозумілу серверу БД, і передає їх серверу БД.
Потім сервер БД виконує роботу по обслуговуванню запиту і повертає результат програмі-розширенню серверної частини. Нарешті та перетворює результати у формат, прийнятний для броузера, і передає їх Web-сервера, а той у свою чергу - броузеру.

4.2.1. Програми розширення серверної частини
Однією з головних причин використання програм-розширень серверної частини на проміжному рівні є можливість використовувати стандарти, що існують для двох крайніх рівнів, шляхом здійснення трансляції між ними. Інші застосування розширень серверної частини складаються в підтримці з'єднань між БД з метою зменшити трафік в мережі і в підтримці резерву з'єднань між БД для зменшення витрат ресурсів на відкриття/закриття БД. Розширення серверної частини також підтримують взаємозамінність у своїх стандартних інтерфейсів. Тому Web-сервери і сервери БД можна порівняно легко замінювати або нарощувати.
Існує три категорії розширень серверної частини: зі звичайним CGI, з гібридним CGI і з API.

5. Приклад бази даних
Приклад бази даних див у доданому до курсової роботи технічному завданні.


Джерела:

1. А. Горев, С. Макашаріпов, Ю. Владимиров
"SQL Server 6.5 Для професіоналів"
Изд. "Питер" Санкт-Петербург 1998

2. К. Ланг, Д. Чоу
"Публікація баз даних в Інтернеті"
Изд. "Символ-Плюс" Санкт-Петербург 1998

3. Д. Боуман, C. Емерсон, М. Дарновскі
"Практичний посібник з SQL"
Изд. "Діалектика" Київ 1997

4. Microsoft Press
"Секрети створення інтрамережі"
Изд. "Питер" Санкт-Петербург 1998

5. http:www.citforum.ru
3


12