ЗМІСТ
ВСТУП
1. АРХІТЕКТУРА ІНФОРМАЦІЙНОЇ СИСТЕМИ
1.1 Архітектура файл-сервер
1.2 Архітектура клієнт-сервер
1.3 Мови запитів (SQL, QBE)
2. РОЗРОБКА ДОДАТКІВ архітектури клієнт-сервер ЗА ДОПОМОГОЮ SQL
2.1 Забезпечення безпеки
2.2 Мова SQL
2.3 Організація взаємодії клієнт-сервер за допомогою SQL
2.4 Середовища програмування на мові SQL
ВИСНОВОК
СПИСОК ЛІТЕРАТУРИ
ВСТУП
Протягом останніх десяти років фахівці з обчислювальної техніці працюють над удосконаленням додатків клієнт-сервер. В результаті були побудовані додатки, що підтримують спільну роботу безлічі користувачів з єдиним джерелом даних у мережі.
Архітектура клієнт-сервер стала загальнопоширеною при спілкуванні з комп'ютером або з системою на його основі. Будь-яка людина, що підключається до діалогової інформаційній системі за допомогою телефонного зв'язку, використовує архітектуру клієнт-сервер. Користуючись автоматичним касовим апаратом, зчитуючи штрихові коди своїх покупок на перевірочному пристрої магазина або розплачуючись за них за допомогою кредитної картки, йде взаємодія з комп'ютерною системою клієнт-сервер.
Метою курсової роботи є розгляд структурованого мови запитів SQL, за допомогою якого розробляються бази даних для системи клієнт-сервер.
Завданнями курсової роботи є розгляд:
1) архітектури інформаційної системи, і зокрема клієнт-сервер;
2) мов запитів SQL і QBE, і їх порівняння;
3) принципів розробки додатків архітектури клієнт-сервер за допомогою SQL.
Система клієнт-сервер є найбільш перспективною, оскільки підтримує велике число користувачів і складні додатки, крім цього вона володіє високим рівнем захисту інформації, за рахунок середовища програмування SQL Server і всі дані і прикладні засоби зберігаються централізовано, тобто, зосереджені в одному місці.
1. АРХІТЕКТУРА ІНФОРМАЦІЙНОЇ СИСТЕМИ
Ефективність функціонування інформаційної системи багато в чому залежить від її архітектури. В даний час перспективною є архітектура клієнт-сервер. У досить поширеному варіанті вона передбачає наявність комп'ютерної мережі та розподіленої бази даних, що включає корпоративну базу даних (КБД) і персональні бази даних (ПБД). КБД розміщується на комп'ютері-сервері, ПБД розміщуються на комп'ютерах співробітників підрозділів, є клієнтами корпоративної бази даних.
1.1 Архітектура файл-сервер
Найпростішою архітектурою для реалізації є архітектура "Файл-сервер" (рисунок 1), але вона ж володіє і найбільшим кількістю недоліків, що обмежують спектр вирішуваних нею завдань. Найпростішим випадком є ​​випадок, коли дані розташовуються фізично на тому ж комп'ютері, що і сама програма.
Малюнок 1 Структура інформаційної системи з файл-сервером
До істотних незручностей, що виникають при роботі з системою, побудованої за такою архітектурі, можна віднести наступне:
- труднощі при забезпеченні несуперечності та цілісності даних;
- істотна завантаження локальної мережі переданими даними;
- в цілому, невисока швидкість обробки і представлення інформації;
- високі вимоги до ресурсів комп'ютерів. При цьому виникають наступні обмеження.
- неможливість організації рівноправного одночасного доступу; користувачів до одного і того ж ділянки бази даних;
- кількість одночасно працюють із системою користувачів не перевищує п'яти осіб для ЛВС, побудованої у відповідності зі специфікацією 1 OBaseT (швидкість обміну даними до 10Мб/с);
При всьому цьому система володіє однією дуже важливою перевагою - низькою вартістю.
Архітектура "файл-сервер" передбачає концентрацію обробки на робочих станціях. Основною перевагою цього варіанту є простота і відносна дешевизна. Подібне рішення прийнятно, поки число користувачів, що одночасно працюють з базою даних, не перевищує 5-10 чоловік. При збільшенні кількості користувачів система може "Захлинутися" через перевантаженість ЛВС великими потоками необробленої інформації.
Сервер, як правило, - наймогутніший і найнадійніший комп'ютер. Він обов'язково підключається через джерело безперебійного живлення, в нім передбачаються системи подвійного або навіть потрійного дублювання. В особливо відповідальних випадках можна підключити разом кілька серверів так, що при виході з ладу одного з них в роботу автоматично включиться "дублер". Таким чином, при концентрації обробки даних на сервері надійність системи в цілому обмежується тільки матеріальними засобами, які замовники готові вкласти в технічне оснащення.
Рішення по автоматизації обліку і управління в корпоративних структурах припускає розподілену обробку даних, організацію паралельних обчислень, глибоке розмежування рівнів доступу, можливість вибору різних операційних систем і серверних платформ. Якщо бізнес не великий, подібне рішення оптимально.
У ході експлуатації були виявлені загальні недоліки файл-серверного підходу при забезпеченні багатокористувацького доступу до бази даних.
Весь тягар обчислювального навантаження при доступі до бази даних лягає на додаток клієнта, що є наслідком принципу обробки інформації в системах "файл-сервер": при видачі запиту на вибірку інформації з таблиці вся таблиця бази даних копіюється на клієнтське місце, і вибірка здійснюється на клієнтському місці. Локальні СУБД використовують так званий "навігаційний підхід", орієнтований на роботу з окремими записами.
Не оптимально витрачаються ресурси клієнтського комп'ютера та мережі; наприклад, якщо в результаті запиту ми повинні отримати 2 записи з таблиці обсягом 10000 записів, всі 10000 записів будуть скопійовані з файл-сервера на клієнтський комп'ютер; внаслідок зростає мережевий трафік і збільшуються вимоги до апаратних потужностей для користувача комп'ютера.
У базі даних на файл-сервері набагато простіше вносити зміни в окремі таблиці, минаючи додатка. Ця можливість полегшується тим обставиною, що у локальних СУБД база даних - поняття більш логічне, ніж фізичне, оскільки під базою даних розуміється набір окремих таблиць, співіснують в єдиному каталозі на диску. Все це дозволяє говорити про низький рівні безпеки - як з точки зору розкрадання та завдання шкоди, так і з точки зору внесення помилкових змін.
Недостатньо розвинений апарат транзакцій для локальних СУБД служить потенційним джерелом помилок як з точки зору одночасного внесення змін в одну і ту ж запис, так і з точки зору відкату результатів серій об'єднаних за змістом в єдине ціле операцій над базою, коли деякі з них завершилися неуспішне, а деякі - ні; це може порушувати посилальну і смислову цілісність бази даних.
Недоліки настільних СУБД зазвичай проявляються не відразу, а лише в процесі тривалої експлуатації, коли обсяг збережених даних і число користувачів стають досить великі - це призводить до зниження продуктивності додатків, що використовують такі СУБД.
Оскільки настільні СУБД не містять спеціальних додатків і сервісів, які управляють даними, а використовуються для цієї мети файлові сервіси операційної системи, вся реальна обробка даних в таких СУБД здійснюється в клієнтському додатку, та будь-які бібліотеки доступу до даних в цьому випадку також знаходяться в адресному просторі клієнтського додатку. Тому при виконанні запитів дані, на підставі яких виконується такий запит, повинні бути доставлені в той же самий адресний простір клієнтського додатка. Це і призводить до перевантаження мережі при збільшенні кількості користувачів і обсягу даних, а також загрожує іншими неприємними наслідками, наприклад руйнуванням індексів і таблиць. Недарма досі популярні утиліти для "Ремонту" зіпсованих файлів настільних СУБД.
Недоліки архітектури "файл-сервер" вирішуються при перекладі додатків в архітектуру "клієнт-сервер", я...
