Lektsiyi ріас

Лекція 1:
Архітектура і принципи розподіленого підходу. Вимоги та критерії побудови інформаційних систем на базі розподілених баз даних (РБД).
Під розподіленої (Distributed DataBase – DDB) зазвичай розуміють базу даних, декомпозовану і фрагментовану на кілька вузлів обчислювальної мережі, з можливим управлінням різними СУБД.
[ Cкачайте файл, чтобы посмотреть ссылку ]
РБД повинна володіти (вимоги):
1. Локальними і глобальними (розподіленими) засобами доступу до даних (СКБД).
2. Однакової логікою прикладних програм у всіх АРМах мережі.
3. Малим часом реакції на запити користувачів.
4. Надійністю, яка виключає руйнування цілісності системи в разі виходу з ладу її окремих компонент (вузлів).
5. Відкритістю, що дозволяє нарощувати обсяг локальних БД і додавати нові АРМ.
6. Розвинений системою управління резервного копіювання і відновлення даних на випадок збоїв.
7. Захищеності, яка стежить за дотриманням привілеїв доступу до даних.
8. Високу ефективність, за рахунок вибору оптимальних алгоритмів використання мережевих ресурсів.
9. Розвиненим реплікаційним механізмом, що дозволяє розміщувати оновлені копії даних в мережі оптимальним чином.
Принципи побудови РБД:
1. Мінімізація інтенсивності обміну даними (мережевого трафіку).
2. Оптимальним розміщенням серверних і клієнтських додатків в мережі.
3. Декомпозиція даних на часто і рідко використовувані сегменти (для правильного налаштування реплікації – розміщення найбільш часто використовуваних даних на АРМ кінцевих користувачів).
4. Періодичне збереження копій даних і виконання дій з підтримки цілісності розподіленої інформаційної системи.
Критерії побудови РБД:
1. Всебічний аналіз інформаційних потреб предметної області з виявленням обсягів збережених даних, їх складності, достовірності, взаємозв’язку.
2. Моделювання передбачуваного мережевого трафіку при роботі РБД з різними моделями реплікації даних.
3. Кластеризація елементів даних і програм їх обробки. Мета – домогтися максимальної автономності та слабозв’язаності кластерів.
4. Прив’язка кластерів даних до ймовірних користувачам або АРМ.
5. Підтримка еталонної копії даних і обмеження реплікаційного механізму.
6. Розробка і реалізація правил приведення локальної і центральної БД в несуперечливий стан.
Розподілені архітектури БД прийнято поділяти за типами на:
Системи не дублюючого розбиття (при великому обсязі часто мінливих даних).
Системи часткового дублювання (при невеликому обсязі часто мінливих даних).
Системи повного дублювання (при невеликому обсязі рідко мінливих даних).
У висновку сформулюємо ряд властивостей, яким по К. Дейту повинна задовольняти РБД:
Локальна автономія. Ця властивість означає, що управління даними на кожному з вузлів розподіленої системи виконується локально. База даних, розташована на одному з вузлів, є невід’ємним компонентом розподіленої системи. Будучи фрагментом загального простору даних, вона в той же час функціонує як повноцінна локальна база даних; управління нею виконується локально і незалежно від інших вузлів системи.
Незалежність вузлів. В ідеальній системі всі вузли рівноправні і незалежні, а розташовані на них бази є рівноправними постачальниками даних у спільний простір даних. База даних на кожному з вузлів самодостатня – вона включає повний власний словник даних і повністю захищена від несанкційованого доступу.
Безперервні операції. Цю властивість можна трактувати як можливість безперервного доступу до даних в рамках DDB незалежно від їх розташування і незалежно від операцій, що виконуються на локальних вузлах. Цю властивість можна виразити гаслом "дані доступні завжди, а операції над ними виконуються безперервно".
Прозорість розташування. Ця властивість означає повну прозорість розташування даних. Користувач, який звертається до DDB, нічого не повинен знати про реальне, фізичне розміщення даних в вузлах інформаційної системи. Всі операції над даними виконуються без урахування їх місцезнаходження. Транспортування запитів до баз даних здійснюється вбудованими системними засобами.
Прозора фрагментація. Ця властивість трактується як можливість розподіленого (тобто на різних вузлах) розміщення даних, що логічно становлять єдине ціле. Існує фрагментація двох типів: горизонтальна і вертикальна. Перша означає зберігання рядків однієї таблиці на різних вузлах (фактично, зберігання рядків однієї логічної таблиці в декількох ідентичних фізичних таблицях на різних вузлах). Друга означає розподіл стовпців логічної таблиці по декількох вузлах.
Прозоре тиражування. Тиражування даних – це асинхронний (в загальному випадку) процес перенесення змін об’єктів вихідної бази даних в бази, розташовані на інших вузлах розподіленої системи. В даному контексті прозорість тиражування означає можливість перенесення змін між базами даних засобами, невидимими користувачеві розподіленої системи. Дана властивість означає, що тиражування можливе і досягається внутрішньо системними засобами.
Обробка розподілених запитів. Ця властивість DDB трактується як можливість виконання операцій вибірки над розподіленою базою даних, сформульованих в рамках звичайного запиту на мові SQL. Тобто операцію вибірки з DDB можна сформулювати за допомогою тих же мовних засобів, що і операцію над локальною базою даних.
Обробка розподілених транзакцій. Цю властивість DDB можна трактувати як можливість виконання операцій оновлення розподіленої бази даних (INSERT, UPDATE, DELETE), що не руйнує цілісність і узгодженість даних. Ця мета досягається застосуванням двофазового або двофазного протоколу фіксації транзакцій (two-phase commit protocol), що став фактичним стандартом обробки розподілених транзакцій. Його застосування гарантує узгоджена зміна даних на декількох вузлах в рамках розподіленої (або, як її ще називають, глобальної) транзакції.
Прозорість мережі. Доступ до будь-яких баз даних може здійснюватися по мережі. Спектр підтримування конкретної СУБД мережевих протоколів не повинен бути обмеженням системи з розподіленими базами даних. Дана якість формулюється максимально широко – в розподіленій системі можливі будь-які мережеві протоколи.
Незалежність від обладнання. Ця властивість означає, що в якості вузлів розподіленої системи можуть виступати комп’ютери будь-яких моделей і виробників – від мейнфреймів до "персоналок".
Незалежність від операційних систем. Ця властивість випливає з попереднього і означає різноманіття операційних систем, керуючих вузлами розподіленої системи.
Незалежність від систем управління. Ця властивість означає, що в розподіленій системі можуть мирно співіснувати СУБД різних виробників і можливі операції пошуку і поновлення в базах даних різних моделей і форматів.

Лекція 2:
Багатовимірне представлення даних. Загальна схема організації сховища даних. Характеристики, типи і основні відмінності технологій OLAP і OLTP. Схеми зірка і сніжинка. Агрегування.
Сховище даних і OLAP. Призначення. Основні характеристики.
Сховище даних (Data Warehouse) – предметно-орієнтований, інтегрований, прив’язаний до часу і незмінний набір даних, призначений для підтримки прийняття рішень.
Сховище даних містить несуперечливі консолідовані історичні дані і надає інструментальні засоби для їх аналізу з метою підтримки прийняття стратегічних рішень. Інформаційні ресурси сховища даних формуються на основі фіксованих протягом тривалого періоду часу моментальних знімків баз даних оперативної інформаційної системи і, можливо, різних зовнішніх джерел. У сховищах даних застосовуються технології баз даних, OLAP, глибинного аналізу даних, візуалізації даних.
Основні характеристики сховищ даних:
містить історичні дані;
зберігає докладні відомості, а також частково і повністю узагальнені дані;
дані в основному є статичними;
нерегламентований, неструктурований і евристичний спосіб обробки даних;
середня і низька інтенсивність обробки транзакцій;
непередбачуваний спосіб використання даних;
призначений для проведення аналізу;
орієнтований на предметні області;
підтримка прийняття стратегічних рішень;
обслуговує відносно мала кількість працівників керівної ланки.
Термін OLAP (On-Line Analytical Processing) служить для опису моделі представлення даних і відповідно технології їх обробки в сховищах даних. В OLAP застосовується багатовимірне уявлення агрегованих даних для забезпечення швидкого доступу до стратегічно важливої інформації з метою поглибленого аналізу. Застосування OLAP повинні володіти наступними основними властивостями:
багатовимірне представлення даних;
підтримка складних розрахунків;
правильний облік чинника часу.
Переваги OLAP:
підвищення продуктивності виробничого персоналу, розробників прикладних програм. Своєчасний доступ до стратегічної інформації.
надання користувачам достатніх можливостей для внесення власних змін в схему.
застосування OLAP спираються на сховища даних і системи OLTP, отримуючи від них актуальні дані, що дає збереження контролю цілісності корпоративних даних.
зменшення навантаження на системи OLTP і сховища даних.
OLAP і OLTP. Характеристики та основні відмінності.
OLAP
OLTP

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

Обсяг аналітичних БД як мінімум на порядок більше обсягу оперативних. Для проведення достовірного аналізу і прогнозування в сховищі даних потрібно мати інформацію про діяльність корпорації та стан ринку протягом декількох років.
Для оперативної обробки потрібні дані за кілька останніх місяців.

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

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

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

Інформація аналітичних БД настільки критична для корпорації, що потрібна велика грануляція захисту (індивідуальні права доступу до певного рядка і / або стовпця таблиці).
Для систем обробки даних зазвичай вистачає захисту інформації на рівні таблиць.

Правила Кодда для OLAP систем
У 1993 році Кодд опублікував працю під назвою "OLAP для користувачів-аналітиків: яким він повинен бути". У ньому він виклав основні концепції оперативної аналітичної обробки і визначив 12 правил, яким повинні задовольняти продукти, що надають можливість виконання оперативної аналітичної обробки.
1. Концептуальне багатовимірне уявлення. OLAP-модель повинна бути багатовимірною в своїй основі. Багатовимірна концептуальна схема або призначене для користувача подання полегшують моделювання та аналіз так само, втім, як і обчислення.
2. Прозорість. Користувач здатний отримати всі необхідні дані з OLAP-машини, навіть не підозрюючи, звідки вони беруться. Незалежно від того, є OLAP-продукт частиною коштів користувача чи ні, цей факт повинен бути непомітний для користувача. Якщо OLAP надається клієнт-серверними обчисленнями, то цей факт також, по можливості, повинен бути невидимий для користувача. OLAP повинен надаватися в контексті істинно відкритої архітектури, дозволяючи користувачеві, де б він не знаходився, зв’язуватися за допомогою аналітичного інструменту з сервером. На додаток до цього прозорість повинна досягатися і при взаємодії аналітичного інструмента з гомогенним і гетерогенним середовищами БД.
3. Доступність. OLAP повинен надавати свою власну логічну схему для доступу в гетерогенне середовище БД і виконувати відповідні перетворення для надання даних користувачеві. Більш того, необхідно заздалегідь подбати про те, де і як, і які типи фізичної організації даних дійсно будуть використовуватися. OLAP-система повинна виконувати доступ тільки до дійсно потрібних даних, а не застосовувати загальний принцип "кухонної лійки", який тягне непотрібне введення.
4. Постійна продуктивність при розробці звітів. Продуктивність формування звітів не повинна істотно падати з ростом кількості вимірювань і розмірів бази даних.
5. Клієнт-серверна архітектура. Потрібно, щоб продукт був не тільки клієнт-серверним, а й щоб серверний компонент був би досить інтелектуальним для того, щоб різні клієнти могли підключатися з мінімумом зусиль і програмування.
6. Загальна багатовимірність. Всі вимірювання повинні бути рівноправні, кожний вимір має бути еквівалентним і в структурі, і в операційних можливостях. Правда, допускаються додаткові операційні можливості для окремих вимірів (мається на увазі час), але такі додаткові функції повинні бути надані будь-якому вимірюванню. Не повинно бути так, щоб базові структури даних, обчислювальні або звітні формати були більш властиві якомусь одному вимірюванню.
7. Динамічне управління розрідженими матрицями. OLAP системи повинні автоматично налаштовувати свою фізичну схему в залежності від типу моделі, обсягів даних і розрідженості бази даних.
8. Багатокористувацька підтримка. OLAP-інструмент повинен надавати можливості спільного доступу (запиту і доповнення), цілісності та безпеки.
9. Необмежені перехресні операції. Всі види операцій повинні бути дозволені для будь-яких вимірювань.
10. Інтуїтивна маніпуляція даними. Маніпулювання даними здійснювалося за допомогою прямих дій над осередками в режимі перегляду без використання меню і множинних операцій.
11. Гнучкі можливості отримання звітів. Виміри повинні бути розміщені в звіті так, як це потрібно користувачеві.
12. Необмежена розмірність і число рівнів агрегації. Дослідження про можливі необхідні вимірювання, які потрібні в аналітичній моделі, показало, що одночасно може використовуватися до 19 вимірювань. Звідси випливає нагальна рекомендація, щоб аналітичний інструмент був здатний одночасно надати як мінімум 15 вимірювань, а краще 20. Більш того, кожне з загальних вимірювань не повинно бути обмежене за кількістю визначених користувачем-аналітиком рівнів агрегації і шляхів консолідації.

Основні елементи і операції OLAP
В основі OLAP лежить поняття гіперкуба, або багатомірного куба даних, в осередках якого зберігаються аналізовані дані.
Факт – це числова величина яка розташовується в осередках гіперкуба. Один OLAP-куб може мати одну або декілька показниками.
Вимірювання (dimension) – це безліч об’єктів одного або декількох типів, організованих у вигляді ієрархічної структури і забезпечують інформаційний контекст числового показника. Вимірювання прийнято візуалізувати у вигляді ребра багатовимірного куба.
Об’єкти, сукупність яких і утворює вимір, називаються членами вимірювань (members). Члени вимірювань візуалізуються як точки або ділянки, що відкладаються на осях гіперкуба.
Осередок (cell) – атомарна структура куба, відповідна повного набору конкретний значень вимірів.
Ієрархія – групування об’єктів одного виміру в об’єкти більш високого рівня. Наприклад, день-місяць-рік. Ієрархії в вимірах необхідні для можливості агрегації і деталізації значень показників згідно їх ієрархічної структури. Ієрархія цілком ґрунтується на одному вимірі і формується з рівнів.
В OLAP-системах підтримуються наступні базові операції:
поворот;
проекція. При проекції значення в осередках, що лежать на осі проекції, підсумовуються по деякому зумовленої законом;
розкриття (drill-down). Одне зі значень вимірювання замінюється сукупністю значень з наступного рівня ієрархії виміру; відповідно замінюються значення в осередках гіперкуба;
згортка (roll-up / drill-up). Операція, зворотна розкриттю;
перетин (slice-and-dice).

Типи OLAP. Переваги і недоліки
Вибір способу зберігання даних залежить від обсягу і структури детальних даних, вимог до швидкості виконання запитів і частоти оновлення OLAP-кубів. В даний час застосовуються три способи зберігання даних:
1. MOLAP (Multidimensional OLAP).
Детальні і агреговані дані зберігаються в багатовимірній базі даних. Зберігання даних в багатовимірних структурах дозволяє маніпулювати даними як багатовимірним масивом, завдяки чому швидкість обчислення агрегатних значень однакова для будь-якого з вимірів. Однак в цьому випадку багатовимірна база даних виявляється надлишковою, так як багатовимірні дані повністю містять детальні реляційні дані.
Переваги MOLAP:
Висока продуктивність. Пошук і вибірка даних здійснюється значно швидше, ніж при багатовимірному концептуальному погляді на реляційну базу даних.
Структура і інтерфейси найкращим чином відповідають структурі аналітичних запитів.
Багатовимірні СУБД легко справляються з завданнями включення в інформаційну модель різноманітних вбудованих функцій.
Недоліки MOLAP:
MOLAP можуть працювати тільки зі своїми власними багатовимірними БД і ґрунтуються на патентованих технологіях для багатовимірних СУБД, тому є найбільш дорогими. Ці системи забезпечують повний цикл OLAP-обробки і або включають в себе, крім серверного компонента, власний інтегрований клієнтський інтерфейс, або використовують для зв’язку з користувачем зовнішні програми роботи з електронними таблицями.
У порівнянні з реляційними, дуже неефективно використовують зовнішню пам’ять, мають гірші в порівнянні з реляційними БД механізмами транзакцій.
Відсутні єдині стандарти на інтерфейс, мови опису і маніпулювання даними.
Не підтримують реплікацію даних, часто використовується в якості механізму завантаження.
2. ROLAP (Relational OLAP)
ROLAP-системи дозволяють представляти дані, що зберігаються в класичній реляційній базі, в багатовимірній формі або в плоских локальних таблицях на файл-сервері, забезпечуючи перетворення інформації в багатовимірну модель через проміжний шар метаданих. Агрегати зберігаються в тій же БД в спеціально створених службових таблицях. В цьому випадку гіперкуб емулює СУБД на логічному рівні.
Переваги ROLAP:
Реляційні СУБД мають реальний досвід роботи з дуже великими БД і розвинені засоби адміністрування. При використанні ROLAP розмір сховища не є таким критичним параметром, як у випадку MOLAP.
При оперативній аналітичній обробці вмісту сховища даних інструменти ROLAP дозволяють виробляти аналіз безпосередньо над сховищем (бо в переважній більшості випадків корпоративні сховища даних реалізуються засобами реляційних СУБД).
У разі змінної розмірності задачі, коли зміни в структуру вимірювань доводиться вносити досить часто, ROLAP-системи з динамічним поданням розмірності є оптимальним рішенням, так як в них такі модифікації не вимагають фізичної реорганізації БД, як у випадку MOLAP.
Системи ROLAP можуть функціонувати на набагато менш потужних клієнтських станціях, ніж системи MOLAP, оскільки основне обчислювальне навантаження в них лягає на сервер, де виконуються складні аналітичні SQL-запити, що формуються системою.
Реляційні СУБД забезпечують значно вищий рівень захисту даних і хороші можливості розмежування прав доступу.
Недоліки ROLAP:
Обмежені можливості з точки зору розрахунку значень функціонального типу.
Менша продуктивність, ніж у MOLAP. Для забезпечення порівняної з MOLAP продуктивності реляційні системи вимагають ретельного опрацювання схеми БД та спеціальної настройки індексів. Але в результаті цих операцій продуктивність добре налаштованих реляційних систем при використанні схеми "зірка" можна порівняти з продуктивністю систем на основі багатовимірних БД.
3. HOLAP (Hybrid OLAP)
Детальні дані залишаються в тій же реляційній базі даних, де вони спочатку знаходилися, а агрегатні дані зберігаються в багатовимірній базі даних.

Моделювання багатовимірних кубів на реляційній моделі даних.
Схема зірка. Переваги і недоліки
Схема типу зірки (Star Schema) – схема реляційної бази даних, що служить для підтримки багатовимірного уявлення даних, що містяться в ній.
Особливості ROLAP-схеми типу "зірка":
1. Одна таблиця фактів (fact table), яка сильно денормалізована. Є центральною в схемі, може складатися з мільйонів рядків і містить підсумовувані або фактичні дані, з допомогою яких можна відповісти на різні питання.
2. Кілька денормалізованних таблиць вимірів (dimensional table). Мають меншу кількість рядків, ніж таблиці фактів, і містять описову інформацію. Ці таблиці дозволяють користувачеві швидко переходити від таблиці фактів до додаткової інформації.
3. Таблиця фактів і таблиці розмірності пов’язані ідентифікуючими зв’язками, при цьому первинні ключі таблиці розмірності мігрують в таблицю фактів як зовнішні ключі. Первинний ключ таблиці факту цілком складається з первинних ключів всіх таблиць розмірності.
4. Агреговані дані зберігаються спільно з вихідними.
Переваги. Завдяки денормалізації таблиць вимірів, спрощується сприйняття структури даних користувачем і формулювання запитів, зменшується кількість операцій з’єднання таблиць при обробці запитів. Деякі промислові СУБД і інструменти класу OLAP / Reporting вміють використовувати переваги схеми "зірка" для скорочення часу виконання запитів.
Недоліки. Денормалізація таблиць вимірів вносить надмірність даних, зростає необхідний для їх зберігання обсяг пам’яті. Якщо агрегати зберігаються спільно з вихідними даними, то в вимірах необхідно використовувати додатковий параметр – рівень ієрархії.
[ Cкачайте файл, чтобы посмотреть картинку ]
Схема сніжинка. Переваги і недоліки
Схема типу сніжинки (Snowflake Schema) – схема реляційної бази даних, що служить для підтримки багатовимірного уявлення даних, що містяться в ній, є різновидом схеми типу "зірка" (Star Schema).
Особливості ROLAP–схеми типу "сніжинка":
1. Одна таблиця фактів (fact table), яка сильно денормалізована. Є центральною в схемі, може складатися з мільйонів рядків і містити підсумовувані або фактичні дані, з допомогою яких можна відповісти на різні питання.
2. Кілька таблиць вимірів (dimensional table), які нормалізовані на відміну від схеми "зірка". Мають меншу кількість рядків, ніж таблиці фактів, і містять описову інформацію. Ці таблиці дозволяють користувачеві швидко переходити від таблиці фактів до додаткової інформації. Первинні ключі в них складаються з єдиного атрибута (відповідають єдиному елементу вимірювання).
3. Таблиця фактів і таблиці розмірності пов’язані ідентифікують зв’язками, при цьому первинні ключі таблиці розмірності мігрують в таблицю фактів як зовнішні ключі. Первинний ключ таблиці факту цілком складається з первинних ключів всіх таблиць розмірності.
4. У схемі "сніжинка" агреговані дані можуть зберігатися окремо від вихідних.
Переваги. Нормалізація таблиць вимірів на відміну від схеми "зірка" дозволяє мінімізувати надмірність даних і більш ефективно виконувати запити, пов’язані зі структурою значень вимірів.
Недоліки. За нормалізацію таблиць вимірів іноді доводиться платити часом виконання запитів.
[ Cкачайте файл, чтобы посмотреть картинку ]

Лекція 3:
Фізична модель БД. Локальні обчислювальні мережі стандарту Ethernet для робочої групи. Топології і розширення мереж. Моніторинг та управління мережею. Збільшення пропускної здатності мережі. Підвищення безпеки мереж.
Локальні обчислювальні мережі стандарту робочої групи.
В даний час, в області телекомунікаційних технологій високопродуктивні комп’ютерні мережі – найбільш динамічно розвивинута ланка. Зараз, практично в будь-якому офісі, організації комп’ютери об’єднані в локальні мережі, багато – мають виходи в глобальну світову мережу по Інтернет протоколу або іншим LAN протоколам.
На малюнку наведені підродини Ethernet з різною швидкістю передачі даних і деякі стандарти кабельних з’єднань.
[ Cкачайте файл, чтобы посмотреть ссылку ]
Важлива властивість мереж сімейства Ethernet декларує схожість в правилах побудови мережевих топологій.
Основні поняття мережевої термінології:
1. Пристрій, що є джерелом / приймачем мережевого трафіку називається вузлом. Вузол завжди має мережеву адресу. Приклади вузлів: комп’ютер, принтер, маршрутизатор, HUB.
2. Кабелем називається кілька провідників, об’єднаних загальною захисною оболонкою. Провідниками можуть бути як мідні або сталеві дроти, так і скловолокна.
3. Ділянка мережі, виконаний з кабелю одного типу, називається кабельним сегментом.
4. Підключення вузлів по довжині коаксіального сегмента називається шинною топологією.
[ Cкачайте файл, чтобы посмотреть картинку ]
5. Підключення вузлів до центрального концентратора за допомогою крученої пари або оптоволоконного кабелю точкового сегмента називається зіркоподібною топологією.
[ Cкачайте файл, чтобы посмотреть картинку ]
6. Концентратор (HUB) – пристрій, що повторює всі сигнали (в тому числі і колізійні) по всіх портах.
7. Маршрутизатор – пристрій, що дозволяє визначати і призначати маршрут слідування сигналів.
8. Міст – пристрій, що дозволяє фільтрувати сигнали мережі і пропускати певні пакети. Є 2 режими роботи: режим навчання & режим фільтрації
9. Локальна обчислювальна мережа (ЛОМ) – це набір з’єднаних кабельним сегментом пристроїв, які отримують одні і ті ж пакети даних (трафік) у вигляді стандартних сигналів.
Отже, в мережі всі пристрої посилають пакети і "слухають" один одного. Поява на деякому вузлі пакетів від різних адресатів в один і той же момент часу називається колізією. Вузли, які потратили в неї випадково в обраний проміжок часу повторюють спробу послати пакет. Відсутність колізій вказує вузлу на успішне проходження пакета.
Нескладно визначити максимальний період кругового звернення пакета – це час проходження колізійного пакета між двома найбільш віддаленими вузлами мережі (туди і назад). Тоді колізійною областю називається зона оповіщення (про колізії) всіх вузлів мережі протягом максимального періоду кругового звернення.
Стандарт IEEE 802.x визначає ЛВС як колізійну область.
Проектування мереж робочої групи (інженерний підхід)
Зазвичай починається з вибору кабельних систем. Розглянемо деякі, найбільш використовувані в практичній області, види кабелів.
Тонкий коаксіальний кабель (діаметр до 5 мм). Виконується з оболонкою із:
полівінілхлориду (PVC-кабель)
тефлону (FEP-кабель)
Пропускна здатність: 10 Мбіт / сек.
Підключення вузлів в шинній топології через Т-образні BNC-з’єднувачі
Мінімальна довжина сегмента: 0.5 м
Максимальна довжина сегмента: 185 м
Максимальне число підключень вузлів до одного кабельного сегменту: 30
особливості:
вимагає кінцевих 50–омних заглушок
не вимагає заземлення.
Товстий коаксіальний кабель (діаметр до 10 мм). Виконується з оболонкою із:
полівінілхлориду (PVC-кабель)
тефлону (FEP-кабель).
Пропускна здатність: 10 Мбіт / сек.
З’єднувальні елементи: роз’єм N-series
Мінімальна довжина сегмента: 2.5 м.
Максимальна довжина сегмента: 500 м.
Максимальне число підключень вузлів до одного кабельного сегменту: 100
особливості:
вимагає установки кінцевих заглушок
вимагає заземлення в одній точці
Кабель з крученими парами. Виконується у вигляді:
4-х парного кабелю
кабельного джгута з 25 і більше пар
Буває екранований (STP, FTP) і неекранований (UTP)
Ділиться на наступні категорії по смузі пропускання:
3–категорія (level 3) 15МГц STP, FTP, UTP
4–категорія (level 4) 20МГц STP, FTP, UTP
5–категорія (level 5) 100 МГц STP, FTP, UTP
5e–категорія (поліпшена lеvе1 5) 100 МГц STP, FTP, UTP
6–категорія (клас Е) 200 МГц STP, FTP, UTP
7–категорія (клас F) 600 МГц S-STP
Пропускна здатність:
10 Мбіт / с – всі категорії
100 Мбіт / с – 5,5е, 6,7 категорії
1000 Мбіт / с – 5е, 6,7 категорії
З’єднувальні елементи: розетки і вилки
8 контактні RJ-45 – 3,4,5,5е, 6 категорії
гібридні RJ-45 – 7 категорії
50 контактний роз’єм Telco
Максимальна довжина сегмента:
без посилення сигналу до 150 м;
з підсилювачем сигналу – до 225 м (level 5 і вище)
Тестування кручений пари
1. Схема з’єднань
2. Довжина сегмента
3. Погонне загасання (ослаблення сигналу з віддаленням від джерела)
4. Перехідне (наведене) загасання на ближньому / дальньому кінці (вплив сигналу однієї пари на іншу)
5. Сигнал-шум
Фактори збільшення пропускної здатності
1. Чистота металу (міді)
2. Мідний дріт збільшеного діаметру (знижує погонне згасання)
3. Застосування спеціальних роздільників між парами
Оптоволоконний кабель. Зазвичай складається з двох пучків оптоволокна, але може бути і один світловод. Співвідношення діаметрів серцевини хвиле-ведучої жили / навколишнього шару 50/125 мікрон, 62 / 5.125 мікрон для багатомодового кабелю і 8/125 – для одномодового.
Багатомодове і одномодове оптоволокно відрізняється ємністю і способом проходження сигналу. Так для багатомодового оптоволокна з незалежних світловим шляхам (модам) можуть передаватися сигнали з різними довжинами хвиль або фазами. Діаметр світло провідної жили (50 або 62.5 мікрона) вибирається з міркувань мінімальної дисперсії відбитого від поверхні серцевини променя. Пропускна здатність багатомодового оптоволокна може змінюватися в межах від 2.5 до 10 Гбіт / сек.
Одномодове оптоволокно передає сигнал тільки з однієї довжиною хвилі або фазою. Малий діаметр світловода (8 мікрон) забезпечує меншу відображену дисперсію, що в свою чергу збільшує довжину сегмента до 2 км. Пропускна здатність одномодового оптоволокна > 10 Гбіт / сек (30–60 Гбіт / сек). Електронно оптичні компоненти одномодового оптоволокна дорожчі багатомодового.
Топологія мережі – зірка або кільце.
Оптоволоконний джгут може містити довільне число світловодів (зазвичай кратну 6). Стандарт не обумовлює їх кількість, тому проектувальник повинен сам визначити скільки йому необхідно багатомодових і одномодових пар.
Кабель, в якому частина світловодів – одномодова (~ 25%), а інша – багатомодова (~ 75%), називається гібридним.
При виборі оптоволоконного кабелю необхідно враховувати:
1. Довжину (не можна помилятися в меншу сторону, так як оптоволоконний кабель дорогий, що не надійно і трудомістко з’єднувати)
2. Діаметр світловодів (зазвичай 62.5 мікрона для багатомодового і 8 мікрон для одномодового)
3. Оптичне вікно – довжина хвилі лазерного обладнання (850 1300, 1310, 1550 нм)
4. Згасання (аналог опору для мідного кабелю)
5. Пропускну здатність приймаючої / передавального обладнання
6. Якість оптоволокна (стандартне, високоякісне, преміум)
Розширення при топології "зірка" проводиться через спеціальний порт маршрутизаторів:
[ Cкачайте файл, чтобы посмотреть картинку ]
З’єднання шинних сегментів:
[ Cкачайте файл, чтобы посмотреть ссылку ]
Можлива також змішана топологія. При цьому комутаційне обладнання повинно підтримувати режим dual speed.
Засоби управління ЛВС
Управління мережею розділяється на
управління пристроями
управління трафіком
Засоби:
Агенти SNMP (Simple Network Multiply Protocol)
Агенти середовища аналізу трафіку
внутрішньо порожнинне спостереження
поза смугове спостереження
розподілене спостереження
Програмно-апаратна підтримка:
Термінальна консоль (пряме підключення, режим VT100, управління через консольні порти)
Консоль управління ланцюжком (ПЕОМ, ОС, спеціальне програмне забезпечення, з’єднання з концентратором 0-модемним або коаксіальним кабелем)
Консоль мережевого трафіку (ПЕОМ, ОС, розвинене програмне забезпечення, з’єднання з концентратором через стандартний порт RJ45)
Оцінюючий коефіцієнт насиченості колізійної області мережі:
LAN =[ Cкачайте файл, чтобы посмотреть картинку ]
Способи і засоби збільшення пропускної здатності ЛВС
Збільшення пропускної здатності ЛВС може здійснюватися:
пасивно – за рахунок заміни обладнання і збільшення швидкості мережевого обміну з 10 до 100 або 1000 Мбіт / сек
активно – за рахунок розподілу колізійної області за допомогою маршрутизаторів, мостів і комутаторів відповідно до схем трафіку, забезпечуючи цим найкраще використання ширини смуги пропускання сигналів.
Розглянемо точковий сегмент Ethernet.
[ Cкачайте файл, чтобы посмотреть картинку ]
1. Мережа працює повільно при слабкому насиченні колізійної області (LAN << 40%)
Критичне місце – сервер, потрібно розділити його функції і частина перенести на нове обладнання.
[ Cкачайте файл, чтобы посмотреть картинку ]
2. Мережа працює повільно при LAN ~ 40%, тоді можна розділити сегмент на два під сегментні, з’єднавши їх мостом або маршрутизатором. При цьому в кожній колізійної області є свій сервер.
[ Cкачайте файл, чтобы посмотреть картинку ]
3. Якщо всім клієнтам мережі при LAN >> 40% необхідний online доступ до різними серверами, то за умови збалансованого трафіку, рекомендованим рішенням збільшення пропускної здатності мережі є установка комутатора
[ Cкачайте файл, чтобы посмотреть картинку ]
4. За наявності кількох колізійних областей з високим рівнем локального трафіку і одночасно вимагають різноманітного серверного обслуговування, то для збільшення пропускної здатності мережі використовуються маршрутизатори.
[ Cкачайте файл, чтобы посмотреть картинку ]
Захист інформації та підвищення безпеки роботи в ЛВС
Захист може бути:
фізичний – закладається при проектуванні мережі і включає заходи, що обмежують безпосередній доступ до мережевих пристроїв (закриваються монтажні шафи, спеціальні короби, серверно-комутаційні зони і т.п.)
логічний – на програмно апаратному рівні комутаторів, маршрутизаторів і мостів.
У будь-якій мережі передачі даних важливо, перш за все, обмежити фізичний доступ до мережного обладнання та ліній зв’язку.
Захист мережевого обладнання здійснюється за допомогою вирішення наступних завдань:
вибір правильної конфігурації обладнання та політики контролю. Слід розробити план політики захисту мережі щодо мережевого обладнання та ліній зв’язку. Регулярно виконувати перевірки стану захисту, щоб гарантувати необхідний рівень фізичного захисту.
обмеження доступу до обладнання та забезпечення надійності його електроживлення та охолодження.
контроль прямого доступу до всього мережевого обладнання
забезпечення захисту ліній зв’язку. Всі комунікаційні лінії і мережеві дроти повинні бути захищені від прослуховування.
розробка плану відновлення системи в разі злому
На рівні захисту адміністративного інтерфейсу мережевих пристроїв застосовуються такі заходи:
захист доступу до консолі
використання шифрування паролів
ретельна настройка параметрів ліній зв’язку
використання багаторівневої системи привілеїв доступу
використання інформаційних банерів пристроїв
управління доступом Telnet
управління доступом SNMP (Simple Network Management Protocol – простий протокол мережевого управління)
Безпека мережі на програмному рівні забезпечується наступними заходами.
1. Доступ до мережевих ресурсів надається тільки зареєстрованим користувачам
2. Ведення грамотної політики паролів для облікових записів:
o завдання мінімальної довжини пароля
o завдання терміну дії пароля
o блокування облікового запису при деякому числі невдалих спроб введення
3. Використання брандмауерів (апаратні або програмні засоби обмеження і фільтрації трафіку на стику двох мережевих сегментів)
4. Використання фільтрування пакетів маршрутизаторами (фільтрування проводиться на основі заголовків протоколів)
5. Використання NAT (Network Addres Translation) – дозволяє комп’ютерам мережі не передавати свої IP-адреси, а користуватися одним IP-адресом шлюзового комп’ютера для виходу в другий сегмент мережі.
6. Використання проксі-серверів. Проксі-сервер діє на прикладному рівні моделі OSI на відміну від NAT (мережевий рівень) і виконує функцію ретрансляції даних, приховуючи IP-адрес клієнта.
7. Використання безпечних протоколів, що шифрують передану інформацію.
o Ipsec (складається з двох протоколів AH (Authentication Header) і ESP (Encapsulating Security Payload) виконуючих транспортну функцію і шифрування відповідно)
o L2TP (Layer 2 Tunneling Protocol) створює тунелі в віртуальних приватних мережах і для шифрування використовує інструменти Ipsec
o SSL (Secure Sockets Layer) Складається з двох частин-SSLHP і SSLRP перша відповідає за перевірку справжності друга зашифрованості. (система сертифікатів)
o Kerberos використовується службами каталогу, щоб надати користувачеві єдину точку входу в мережу тобто користувач отримує доступ до всіх ресурсів мережі (Active Directory) (якщо доступ дозволено!) (система передачі квитків TGT, ST).

Лекція 4: Логічна модель РБД. Бізнес-логіка файл-серверної, клієнт-серверної і N-рівневої архітектури.
Логічна модель РБД.
Логічна модель РБД будується на 3–х рівнях (шарах) абстракції даних: подання інформації, обробки (бізнес-логіки) і зберігання. Шари утворюють сувору ієрархію: шар бізнес-логіка взаємодіє з шарами зберігання та подання. Фізично, шари можуть входити до складу одного програмного модуля, або ж розподілятися на декількох паралельних процесах в одному або декількох вузлах мережі.
Шар подання інформації
Забезпечує інтерфейс з користувачем. Як правило, отримання інформації від користувача відбувається за допомогою різних форм. А видача результатів запитів – за допомогою звітів.
Шар бізнес-логіки
Сполучний, саме він визначає функціональність і працездатність системи в цілому. Блоки програмного коду розподілені по мережі і можуть використовуватися багаторазово (CORBA, DCOM) для створення складних розподілених додатків.
Шар зберігання даних
Забезпечує фізичне зберігання, додавання, модифікацію і вибірку даних. На даний шар також покладається перевірка цілісності і несуперечності даних, а також реалізацію розділених транзакцій.
Шари розподіленої системи можуть бути по різному реалізовані і виконуватися в різних вузлах мережі. Зазвичай розглядаються наступні архітектури:
Шар \ Тип архітектури
Файл–сервер
Клієнт–сервер (Бізнес–логіка на клієнті)
Клієнт–сервер (бізнес–логіка на сервері)
N–рівнева архітектура

Уявлення
Клієнт
Клієнт
Клієнт
Клієнт

Бізнес-логіки
Клієнт
Клієнт
Сервер БД
Сервер додатків (комп. кластер)

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

Файл-сервер
У системах, побудованих за архітектурою файл-сервера всі гілки системи представляють єдине і неподільне ціле. БД зберігається у вигляді файлу або набору файлів на файл-сервері. Вся логіка вибірки, зберігання і забезпечення несуперечності даних покладається на клієнтську частину. Файл-серверні системи орієнтовані на роботу з окремими записами в таблиці.
Переваги:
1. Простота логіки.
2. Низькі вимоги до апаратного забезпечення і малий обсяг необхідної пам’яті.
3. Не вимагають надійних багатозадачних і багатокористувацьких ОС.
4. Невисока ціна СУБД.
Недоліки:
1. Обмеженість мови і негнучкість середовища розробки додатків
2. Слабка масштабованість
3. Не забезпечують багато користувачів режим роботи
4. Важко підтримувати цілісність і несуперечність даних
5. Необхідність ручного блокування записів або таблиць цілком.
6. Низький рівень захищеності як зовнішньої (від злому), так і внутрішньої (від помилок додатків) Наприклад індекси окремо від таблиць.
7. Не мають коштів шифрування мережевого трафіку
8. Створюють високе навантаження на мережу
Висновки:
Файл-серверна архітектура є досить привабливою альтернативою для створення одного користувача ІС зі слабкими вимогами до захисту даних.
Клієнт-сервер з бізнес-логікою на клієнті
У даних системах зберігання, вибірка і підтримку несуперечності даних покладається на сервер БД, а вся бізнес-логіка і логіка уявлення виконуються на клієнтських машинах. Так як всі операції з маніпулювання даними здійснюються тільки через сервер, продуктивність і збереження даних залежить тільки від сервера БД. Сервери БД спочатку розраховані на багато користувачів режим роботи, мають ефективні алгоритми кешування даних. Сучасні сервери мають хорошу масштабованість.
Клієнтська частина обмінюється даними з сервером за допомогою SQL запитів. Обробка інформації в клієнт-серверних системах ведеться на рівні безлічі кортежів.
Процес розробки розділяється на створення БД і написання клієнтської частини з бізнес-логікою.
Переваги:
1. Висока продуктивність, стабільність і надійність при багато користувачів роботі.
2. Легко організовується захист даних (шифрування мережевого трафіку SSH, SSL)
3. Універсальність мови визначення і маніпулювання даними
Недоліки:
1. Більш висока ціна СУБД. (Сервер БД продається окремо).
2. Досить високі вимоги до кваліфікації розробників
3. Навички адміністрування сервера БД
4. Підвищені вимоги до пропускної здатності мережі
5. Підвищені вимоги до клієнтських місцях (на них виконується шар бізнес- логіки)
Висновки:
При кількості користувачів від 2 до ~ 50 вона є хорошим варіантом. З ростом числа користувачів починає позначатися недостатня пропускна здатність мережі.
Клієнт-сервер з бізнес-логікою на сервері
Використовується можливість сучасних серверів БД виконувати збережені SQL процедури на сервері, куди і переноситься максимально можлива частина бізнес-логіки. Вимоги до сервера БД зростають, однак різко знижуються вимоги до клієнтських машин (за рахунок виносу з них бізнес-логіки) і до пропускної здатності мережі (клієнту передаються тільки дані, необхідні користувачеві).
Переваги:
1. Знижені, в порівнянні з попереднім класом систем, вимоги до пропускної здатності мережі і клієнтським місцях.
2. Простіший процес створення бізнес-логіки.
Недоліки:
1. Підвищені вимоги до сервера БД. (Кожен сеанс "з’їдає" пам’ять з розрахунку граничного завантаження)
2. Невисока мобільність системи на інші сервери БД.
Висновки:
У порівнянні з попередніми класами, дозволяє тримати велике навантаження.
N-рівнева архітектура
Основними елементами є сервера БД, сервер (кластер) додатків і клієнтська частина. Головна ідея n-рівневої архітектури полягає в максимальному спрощенні клієнта (тонкий клієнт), винесення всієї бізнес-логіки з клієнта і сервера БД.
Тонкий клієнт являє собою певний термінал типу HTML-browser або емулятори X-терміналу
Вся бізнес-логіка оформляється у вигляді набору додатків, що запускаються на сервері додатків під управлінням ОС типу UNIX.
Сервера БД займаються тільки проблемами зберігання, додавання, модифікації і підтримки несуперечності даних.
Сервер додатків з’єднаний з сервером БД за допомогою окремого високошвидкісного сегмента мережі.
Переваги:
1. Підвищена захищеність.
2. Висока продуктивність.
3. Легкість розвитку і модифікації.
4. Легкість адміністрування.
5. Можливість створення системи з масовим паралелізмом (серверів БД може бути кілька, а сервером додатків можуть служити кілька з’єднаних в кластер комп’ютерів).
Недоліки:
1. Висока складність.
2. Висока ціна рішення.
3. У деяких випадках поступається по продуктивності клієнт-серверних систем з бізнес-логікою на сервері.
Висновки:
Єдина альтернатива для створення ІС для дуже великої кількості користувачів.

Лекція 5:
Базові об’єктні архітектури розподілених систем. Технології .NET, (D) COM +, CORBA, EJB.
Базові технології. Порівняння на понятійному рівні.
Функції CORBA і COM – це функції проміжного middleware програмного забезпечення об’єктної середовища. Функціональність об’єкта надається клієнтові за допомогою звернення до абстрактних інтерфейсів. Інтерфейс визначає набір методів, властиві даному класу об’єктів. Клієнт отримує доступ до об’єкту тільки шляхом виклику методу, визначеного в інтерфейсі об’єкта, але деталі реалізації приховані від клієнта. Реальні дії виконуються в адресному просторі об’єкта, можливо, такого далекого по відношенню до процесу клієнта. Приховування деталей реалізації і визначає незалежність від платформи і мови програмування.
[ Cкачайте файл, чтобы посмотреть картинку ]
В обох технологіях взаємодія між клієнтським процесом і сервером об’єкта, тобто процесом, який породжує і обслуговує екземпляри об’єкта, здійснюється за рахунок віддаленого виклику процедур (RPC, remote procedure call). Механізм RPC реалізує схему передачі повідомлень, відповідно до якої в розподіленому клієнт-серверному застосуванні процедура – клієнт передає спеціальне повідомлення з параметрами виклику по мережі в віддалену серверну процедуру, а результати її виконання повертаються в іншому повідомленні клієнтського процесу.
Для цього на стороні клієнта і на стороні сервера підтримуються спеціальні компоненти, що носять назву клієнтський і серверний сурогати (client stub і server stub). Для виклику методу об’єкта клієнт звертається до клієнтського сурогату, який упаковує аргументи на повідомлення-запит і передає їх на транспортний рівень з’єднання. Серверний сурогат розпаковує отримане повідомлення і відповідно до переданих аргументами викликає потрібний метод об’єкта. У СОМ клієнтський сурогат називається proxy, а серверний – stub. У CORBA клієнтський сурогат не має спеціальної назви, а серверний позначається терміном skeleton.
Параметри виклику можуть формуватися у відмінній від серверної мовної та операційному середовищі, тому на клієнтський і серверний сурогати покладаються функції перетворення аргументів і результатів в універсальне, яке залежить від конкретної архітектури уявлення. Тим самим досягається можливість взаємодії клієнта і сервера на різних платформах.
Поняття про технологію (D) COM (+)
(D) COM (+): COM, DCOM, COM +. COM (Component Object Model) – Об’єктно-Компонентна Модель (1993). D – distributed (1996). + – 1998.
У СОМ об’єкт характеризується своїм класом. Клас – це реалізація певної кількості інтерфейсів. Множинне спадкування інтерфейсів не підтримується, замість цього об’єкт може мати кілька інтерфейсів одночасно. У СОМ інтерфейс може визначатися шляхом успадкування іншого інтерфейсу. Для всіх інтерфейсів існує базовий інтерфейс – IUnknown. Для того щоб перейти від інтерфейсу базового типу до успадкованого інтерфейсу або від одного з інтерфейсів об’єкта до іншого, клієнт повинен викликати метод QueryInterface, визначений у базовому інтерфейсі IUnknown.
Для ідентифікації класів і інтерфейсів СОМ використовуються ті ж універсальні унікальні ідентифікатори (UUID), які прийняті для ідентифікації інтерфейсів в специфікації DCE RPC. Можна застосовувати і символьні позначення інтерфейсу, але потім вони повинні бути трансльовані в належний ідентифікатор UUID. Об’єкт в СОМ – це екземпляр класу. Клієнт получає доступ до об’єкту за допомогою покажчика на один з його інтерфейсів (interface pointer). Ідентифікатор класу посилається на конкретну реалізацію, і фактичний набір інтерфейсів для даної реалізації стає остаточно відомий тільки на стадії виконання. СОМ реалізує інтеграцію об’єктів на рівні двійкових кодів.
Microsoft IDL (MIDL) – лише один з можливих способів визначення інтерфейсів об’єкта. У специфікації СОМ підкреслюється, що ця модель реалізує інтеграцію на довічним рівні, тому всі специфікації і стандарти, які стосуються рівню вихідних текстів компонентів розглядаються як допоміжні і не мають вирішального впливу на загальну архітектуру системи.
COM підтримує інтерфейс динамічного виклику (коли інтерфейс об’єкта не відомий клієнту на етапі компіляції).
В COM для ідентифікації об’єктів використовується механізм moniker, який забезпечує перетворення символьного імені об’єкта в покажчик інтерфейсу. Цей механізм діє для тих об’єктів, які зберігаються в довгостроковій пам’яті. Два ж активних об’єкта вважаються ідентичними, якщо для них збігаються покажчики на інтерфейс IUnknown. Для довготривалого зберігання в СОМ підтримуються дві моделі. Перша і початкова модель надає клієнту можливість управляти зберіганням об’єкту. За другою моделі Microsoft Transaction Server (MTS) забезпечує управління зберіганням з боку сервера.
У СОМ передбачені такі загальні служби, як захист (security), управління життєвим циклом (lifecycle managemеnt), інформація про типи (type information), іменування (naming), доступ до баз даних (database access), передача даних (data transfer), реєстрація (registry) і асинхронне взаємодія.
Поняття про технологію CORBA
CORBA (Common Object Request Broker Architecture) – загальна архітектура об’єктних брокерів (загальна архітектура посередників передачі запитів об’єктів). Терміном CORBA позначають технологію, архітектуру і набір специфікацій і стандарти проміжного програмного забезпечення (middleware) об’єктного типу для створення розподілених програмних застосувань. Автором архітектури CORBA є консорціум Object Management Group.
CORBA складається з 4 основних частин.
[ Cкачайте файл, чтобы посмотреть картинку ]
Object Request Broker – брокер (посередник) об’єктних запитів, є ядром архітектури CORBA. Це об’єктна шина, по якій відбувається взаємодія локальних і віддалених об’єктів. Крім самого виклику методу віддаленого об’єкта, ORB відповідає за пошук реалізації об’єкта, його підготовку до отримання та обробки запиту, передачу запиту і доставку результатів клієнту.
Object Services – об’єктні сервіси, реалізації об’єктів, що надають загальні для об’єктно-орієнтованого середовища можливості: служба імен, служба подій, служба збереження в довгостроковій пам’яті, служба транзакцій і так далі.
Common Facilities – спільні кошти, це реалізації об’єктів, необхідні для великого числа додатків, наприклад, підтримка складених документів, потоків завдань і так далі.
Application і Domain Interfaces – прикладні та галузеві інтерфейси. Прикладні об’єкти представляють собою реалізації об’єктів для конкретних користувальницьких застосувань. У CORBA є також поняття домену. Реалізації об’єктів домену (CORBA domains) призначені для додатків з вертикальною організацією.
У CORBA інтерфейс об’єкта задається за допомогою мови опису інтерфейсів (Interface Definition Language, IDL). Тип об’єкта – це тип його інтерфейсу. Інтерфейс ідентифікується ім’ям, представленим ланцюжком символів. У моделі CORBA визначений базовий тип для всіх об’єктів – CORBA :: Object. Об’єкт підтримує тип свого безпосереднього інтерфейсу і за принципом успадкування всі його базові типи.
CORBA IDL задає визначення, які можуть відображатися в безліч різних мов, не вимагаючи при цьому жодних змін від цільового мови. Ці відображення реалізуються компілятором IDL.
CORBA вводить поняття об’єктного посилання (object reference), яке унікальним чином ідентифікує об’єкт в мережі.
Механізм довгострокового зберігання, тобто збереження стану об’єкта в довготривалій пам’яті для подальшої його реактивації, в CORBA абсолютно прозорий для клієнта.
Найбільш поширені служби CORBA – служби іменування, управління життєвим циклом і подіями.
CORBA підтримує інтерфейс динамічного виклику DII (Dynamic Invocation Interface).
У CORBA спочатку була закладена багатоплатформенність і підтримка безлічі популярних мов програмування без необхідності будь-яких змін в них.
Об’єктна архітектура розподілених систем. Поняття про технологію EJB
Властивості архітектури Enterprise JavaBeans:
Є стандартною компонентною архітектурою для побудови розподілених об’єктно-орієнтованих бізнес-застосувань на мові Java.
Побудова розподілених застосувань шляхом комбінування компонентів, розроблених для різних платформ і операційних систем.
Приховування деталей реа
·лізації: розробникам не потрібно знати і розуміти нижні рівні системи.
Відображає всі аспекти життєвого циклу програмного забезпечення.
Сумісна з CORBA-протоколами.
[ Cкачайте файл, чтобы посмотреть картинку ]
Компоненти EJB (The Enterprise JavaBeans component) виконуються всередині EJB-контейнера (The Enterprise JavaBeans container), який, в свою чергу, виконується всередині EJB-сервера. Будь-який сервер, який в змозі підтримувати EJB-контейнери і надавати їм необхідні сервіси, може бути EJB-сервером. EJB-компонент представляє із себе Java-клас, який реалізує якусь бізнес-логіку. Всі інші класи в EJB-системі або реалізують підтримку клієнт / сервер взаємодій між компонентами, або реалізують деякі послуги для компонентів.
Компонент EJB визначається як комбінація трьох складових елементів і опису його установки і застосування:
home-інтерфейс, home-об’єкт,
remote-інтерфейс, об’єкт EJB – реалізація remote –Інтерфейс (EJBObject),
Безпосередньо реалізація Enterprise Bean – це код реалізації бізнес-логіки.
Опис установки EJB і його застосування.
EJB-контейнер реалізує для знаходяться в ньому компонентів такі сервіси, як транзакції (transaction), управління ресурсами, управління версіями компонентів, їх мобільністю, налаштування, мобільністю, життєвим циклом. Розробник EJB-компонента може просто викликати відповідні методи у контейнера.
Клієнтські програми викликають методи на віддалених EJB-компонентах через EJB-об’єкт (EJB-object). EJB-об’єкт реалізує "віддалений інтерфейс" (remote interface) EJB-компонента на сервері. EJB-об’єкт реалізує лише бізнес-інтерфейс для EJB-компонента, будучи, в деякому сенсі, "проміжним" ланкою між клієнтом і EJB-компонентом.
EJB-об’єкти і EJB-компоненти являють собою різні класи. Хоча вони реалізують один і той же інтерфейс (інтерфейс, описаний для EJB-компонента), але при цьому вони виконують зовсім різні функції. EJB-компонент виконується на сервері, усередині EJB-контейнера і реалізує бізнес-логіку, в той час як EJB-об’єкт виконується у клієнта і віддалено викликає методи у EJB-компонента.
Об’єктна архітектура розподілених систем. Поняття про технологію .NET
Під платформою Microsoft.NET слід розуміти інтегровану систему (інфраструктуру) засобів розробки, розгортання і виконання складних, розподілених програмних систем.
[ Cкачайте файл, чтобы посмотреть картинку ]
Операційні системи корпорації Microsoft – Windows 2000 / XP / ME / CE – це базовий рівень платформи MS.Net.
.Net Enterprise Servers є програмними продуктами, використання яких дозволяє знизити складність розробки складних програмних систем (SQL Server).
.Net Building Block Services представляють собою готові "будівельні блоки" складних програмних систем, які можуть бути використані через Інтернет як сервісні послуги. Набір таких сервісів MS.Net планується послідовно розширювати.
Інтегроване середовище розробки застосувань Visual Studio.NET (VS.Net) – верхній рівень MS.Net – забезпечує можливість створення складного ПО на основі платформи Windows.
MS.NET Framework є ядром платформи MS.Net, забезпечуючи можливість побудови і виконання .Net додатків.
[ Cкачайте файл, чтобы посмотреть картинку ]
Тут набір базових класів забезпечує, наприклад, роботу з рядками, введення-виведення даних, багато поточність. Набір класів для роботи з даними надають можливість використання SQL-запитів, ADO.Net і обробки XML даних і так далі.
Загальномовне Виконавча (Common Language Runtime, CLR) активізує виконуваний код, виконує для нього перевірку безпеки, має в своєму розпорядженні цей код в пам’яті і виконує його, забезпечує збірку сміття. Для забезпечення можливості багатомовної розробки ПО програмний код, одержуваний після компіляції програми на одній з алгоритмічних мов платформи MS.Net, представляється на загальному проміжному мовою (Common Intermediate Language або CIL). Збірки (файли на CIL) перед своїм виконанням за допомогою JIT-компілятора (Just-In-Time compilers) переводяться з програмного коду на проміжному мовою (CIL-коду) в машинний (native) код платформи виконання.
Об’єктна архітектура розподілених систем. Загальні риси технологій CORBA і (D) COM (+)
Призначені для розробки складних розподілених систем.
Незалежність від фізичного розміщення об’єктів.
Незалежність від платформи (ОС).
Незалежність від мови програмування.
COM і CORBA реалізовані на базі абстрактного інтерфейсу, тобто мови, який реалізує доступ до вузла.
Об’єкти взаємодіють один з одним за допомогою викликів віддалених процедур (RPC, remote procedure call).
Використовуються об’єкти, розташовані в адресних просторах клієнта і сервера і обмінюються даними між собою.
Клієнт і сервер взаємодіють між собою за допомогою marshalling, що представляє собою обмін даними (передані дані упаковуються в так званий marshalling packet і розпаковуються після передачі в інше адресний простір) і передачу покажчиків на інтерфейси і аргументи функцій між цими об’єктами.
Об’єктні моделі CORBA і COM. Основні відмінності
Тип об’єктів CORBA – типи його інтерфейсів. В COM об’єкт – це екземпляр класу. Базовий тип CORBA-CORBA :: Object. Базовий тип COM – IUnknown.
CORBA підтримує множинне успадкування. Один об’єкт може мати кілька інтерфейсів. В COM кожен об’єкт може мати один інтерфейс. В COM + введено множинне спадкування.
У CORBA використовується ідентифікація, в COM немає явної ідентифікації.
У CORBA активація, збереження або вимкнення здійснюються неявно. В COM ці операції потрібно виконувати явно.
Мова опису інтерфейсу. У CORBA використовується IDL (Interface Definition Language, мова опису інтерфейсів). IDL – мовне середовище без детальної реалізації, нагадує C ++, є компільовані мовою, підтримує зв’язок за даними з Delphi, Ada, Java, C ++, Cobol і так далі. IDL базується на динамічних виклики віддалених процедур. В COM використовується MIDL (Microsoft IDL). Мова MIDL прив’язаний до платформи, є компільовані мовою, здійснює підтримку зв’язків c MJava, Visual C / C ++, VB, використовується в DLL.
Відрізняються структурою внутрішніх об’єктів (служб). CORBA: життєвий цикл, збереження, контроль за доступом, захист, служба колекції, імпорт, експорт, програмовані транзакції. COM: життєвий цикл, захист, інформація про типи, передача даних, реєстрація, асинхронне взаємодія, биті пакети не аналізуються. СОМ-об’єкти можна створювати прямим викликом спеціальних функцій, але безпосередньо знищити його неможливо. Замість прямого знищення використовується механізм самознищення, заснований на підрахунку посилань. В COM використовується сервер транзакцій.
Платформи CORBA: DOS, Windows 3.11, Windows 98, Windows NT, OS / 2, Unix, Solaris. Платформи COM: Windows 2000, Windows XP, Windows 9x і Windows NT, OpenVMS, Solaris.
Ідентифікація об’єктів CORBA і COM в мережі. Основні відмінності
CORBA і СОМ абсолютно по-різному підходять до проблем ідентифікації (identity) об’єктів і їх збереження в довгостроковій пам’яті (persistance). CORBA вводить поняття об’єктної посилання (object reference), яка унікальним чином ідентіфіціруетоб’ект в мережі. Тим самим примірника об’єкта дається право на існування протягом деякого часу. Об’єкти можуть активуватися, зберігатися в довгострокову пам’ять, пізніше знову активувати і деактивувати, і при цьому об’єктне посилання буде вказувати весь час на один і той же конкретним втіленням об’єкта. Для об’єктів, призначених для тривалого використання, об’єктні посилання можуть інтегруватися зі службою каталогів або службою імен. Клієнт не має ніяких легальних засобів виявити, куди і яким чином зберігається екземпляр об’єкта. Служба іменування InteroperableNaming Service призначена для прозорого пошуку і виклику об’єктів, що не залежить від конкретної реалізації ORB.
У СОМ поняття об’єктної посилання відсутня. Найближчий аналог – це механізм moniker, що забезпечує перетворення символьного імені об’єкта в покажчик інтерфейсу. Цей механізм діє для тих об’єктів, які зберігаються в довгостроковій пам’яті. Два ж активних об’єкта вважаються ідентичними, якщо для них збігаються покажчики на інтерфейс IUnknown.
Для довготривалого зберігання в СОМ підтримуються дві моделі. Перша і початкова модель надає клієнту можливість управляти зберіганням об’єкту. Інший, більш пізній варіант збереження в довготривалу пам’ять в СОМ передбачає використання Microsoft Transaction Server (MTS), який забезпечує управління зберіганням з боку сервера.
Мови опису інтерфейсів CORBA і COM. Основні властивості
У CORBA мова опису інтерфейсів – найважливіша частина архітектури, основа схеми інтеграції об’єктів. Всі інтерфейси і типи даних визначаються на IDL. Різні мови програмування підтримуються завдяки заданим відображенням між описами типів даних на IDL в відповідні визначення на конкретній мові. CORBA IDL задає визначення, які можуть відображатися в безліч різних мов, не вимагаючи при цьому жодних змін від цільового мови. Ці відображення реалізуються компілятором IDL, який генерує вихідні коди потрібною мовою. На даний момент підтримується відображення в C, C ++, SmallTalk, Ada, Delphi, Visual Basic, Cobol і Java. Сам IDL синтаксично нагадує декларації типів в Сі ++, але не ідентичний цій мові.
У Microsoft IDL (MIDL) – лише один з можливих способів визначення інтерфейсів об’єкта. Технологія COM реалізує інтеграцію на дочірньому рівні, тому всі специфікації і стандарти, які стосуються рівню вихідних текстів компонентів, є допоміжними і не надають вирішального впливу на загальну архітектуру системи. Мова MIDL прив’язаний до платформи.
MIDL, що є розширенням DCE RPC IDL, не визначає загального набору типів даних, доступних різним мовам програмування. На MIDL можна визначити інтерфейси і типи даних, які відповідають програмам на C, C ++, Visual Basic, Java.
Основні вбудовані об’єктні служби CORBA і COM
Служби COM:
захист (security),
управління життєвим циклом (lifecycle managemеnt),
інформація про типи (type information),
іменування (naming),
доступ до баз даних (database access),
передача даних (data transfer),
реєстрація (registry),
асинхронне взаємодія.
Служби CORBA (16):
іменування (naming),
події (events),
життєвий цикл (life cycle),
довгострокове зберігання об’єктів (persistent),
транзакції (transactions),
контроль за доступом до ресурсів (concurrency control),
відносини (relationsips),
імпорт / експорт (externalization),
запити (query),
ліцензування (licensing),
властивості (property),
час (time),
захист (security),
переговори між об’єктами (object trader),
збір об’єктів (object collections),
служба асинхронного обміну повідомленнями (asynchronous messaging).
Операційні середовища функціонування CORBA і COM. Висновки порівняльного аналізу двох технологій.
Обидві технології розвиваються і ускладнюються.
CORBA є більш універсальною, ніж COM, розрахована на неоднорідну мережу.
CORBA відповідає розподіленої системі галузі, COM – робочій групі.
COM поступається CORBA в організації захисту, управлінні транзакціями і координованих розподілі структур.
Ряд продуктів дозволяє використовувати спільно ці технології.

Лекція 6:
Розподілені СУБД. Архітектура MS SQL Server 2008.
Для кращого розуміння принципів роботи сучасних СУБД розглянемо структуру однієї з найбільш поширених клієнт-серверних СУБД – Microsoft SQL Server 2008. Незважаючи на те, що кожна комерційна СУБД має свої відмінні риси, інформації про те, як влаштована якась із СУБД, зазвичай буває досить для швидкого початкового освоєння іншої СУБД. Короткий огляд можливостей Microsoft SQL Server – 2008 року було наведено в розділі, присвяченому короткому огляду сучасних СУБД. В даному розділі розглянемо основні моменти, пов'язані зі структурою відповідної СУБД (архітектурою бази даних і структурою програмного забезпечення).
Під архітектурою (структурою) бази даних конкретної СУБД будемо розуміти основні моделі представлення даних, що використовуються у відповідній СУБД а також взаємозв'язку між цими моделями.
Логічний рівень (рівень моделі даних СУБД) – засіб представлення концептуальної моделі. Тут кожна СУБД має деякі відмінності, але вони є не дуже значними. Відзначимо, що у різних СУБД істотно відрізняються механізмиперехода від логічного до фізичного рівня уявлення.
Фізичний рівень (внутрішнє подання даних в пам'яті ЕОМ – фізична структура бази даних). Даний рівень розгляду на увазі вивчення бази даних на рівні файлів, що зберігаються на жорсткому диску. Структура цих файлів - особливість кожної конкретної СУБД, в т.ч. і Microsoft SQL Server.
[ Cкачайте файл, чтобы посмотреть картинку ]
Microsoft SQL Server 2008 презентує собою реляційну СУБД (дані представляються у вигляді таблиць). Таким чином, основною структурою моделі даних цієї СУБД є таблиці.
Таблиці містять дані про всіх сутності концептуальної моделі бази даних. При описі кожного стовпчика (поля) користувач повинен визначити тип відповідних даних. Microsoft SQL Server 2008 підтримує як вже традиційні типи даних (символьний рядок з різним поданням, число з плаваючою точкою довжиною 8 або 4 байта, ціле число довжини 2 або 4 байти, дата і час, поле приміток, логічне значення і т. Д. ), так і нові типи даних. Крім етогоMicrosoft SQL Server 2008 надає спеціальний апарат для створення користувацьких типів даних.
Тип даних hierarchyid дозволяє створювати відносини між елементами даних в таблиці, для того, щоб задати позицію в ієрархії зв'язків між рядками таблиці. В результаті використання цього типу даних в таблиці рядки таблиці можуть відображати певну ієрархічну структуру, відповідну зв'язків між даними цієї таблиці.
Просторові дані – це дані, що визначають географічні розташування і форми, переважно на Землі. Це можуть бути орієнтири, дороги і навіть розташування фірми. У SQL Server 2008 є географічні (geography) і геометричні (geometry) типи даних для роботи з цією інформацією. Тип даних geography працює з інформацією для кулястої землі. Модель кулястої землі використовує при розрахунках кривизну земної поверхні. Інформація про стан задається широтою і довготою. Ця модель добре годиться для додатків, пов'язаних з морськими перевезеннями, військовим плануванням і короткостроковими програмами, що мають прив'язку до земної поверхні. Цю модель потрібно використовувати, якщо дані зберігаються у вигляді широт і довгот.
Тип даних geometry працює з планарной моделлю або моделлю плоскою землі. У цій моделі земля вважається плоскою проекцією з певної точки. Модель плоскою землі так само до уваги кривизну поверхні землі, тому використовується, в першу чергу, для опису коротких відстаней, наприклад, в базі даних програми, що описує внутрішню частину будівлі.
Типи geography і geometry створюються з векторних об'єктів, заданих в форматах Well-Known Text (WKT) або Well-Known Binary (WKB). Це формати для перенесення просторових даних, описані в простих функціях відкритого геопространственного консорціуму (Open Geospatial Consortium (OGC) Simple Features) для специфікацій SQL (SQL Specification).
Для кожної таблиці повинен бути визначений первинний ключ - мінімальний набір атрибутів, унікально ідентифікує кожну запис в таблиці. Для реалізації зв'язку між таблицями в одну з пов'язаних таблиць включається додаткове поле (кілька полів) – первинний ключ іншої таблиці. Додатково включені поле або поля в цьому випадку називаються зовнішнім ключем відповідної таблиці. Крім таблиць, в модель даних Microsoft SQL Server 2008 входить ще цілий ряд компонентів.
Індекси створюються для прискорення пошуку потрібної інформації і містять інформацію про впорядкованості даних за різними критеріями. Індексування може бути виконано по одному або кількох стовпців. Індексування може бути вироблено в будь-який момент. Індекс містить ключі, побудовані з одного або декількох стовпців в таблиці або поданні. Ці ключі зберігаються у вигляді структури збалансованого дерева, яка підтримує швидкий пошук рядків по їх ключовим значенням в SQL Server.
Представлення – це віртуальна таблиця, вміст якої визначається запитом. Подання формується на основі SQL-запиту SELECT, який формується за звичайними правилами. Таким чином, уявлення є пойменований запит SELECT.
Як і справжня таблиця, подання складається із сукупності іменованих стовпців і рядків даних. Поки подання не буде проіндексовано, воно не існує в базі даних як збережена сукупність значень. Рядки і стовпці даних беруться з таблиць, зазначених у визначальному уявлення запиті і динамічно створюваних при зверненнях до подання. Подання виконує функцію фільтру базових таблиць, на які вона посилається. Визначальний уявлення запит може бути ініційований в одній або кількох таблицях або в інших уявленнях поточної або інших баз даних. Крім того, для визначення уявлень з даними з декількох різнорідних джерел можна використовувати розподілені запити. Це корисно, наприклад, якщо потрібно об'єднати структуровані таким чином дані, що відносяться до різних серверів, кожен з яких зберігає дані конкретного відділу організації.
Збірки є файлами динамічної бібліотеки, які використовуються в екземплярі SQL Server для розгортання функцій, процедур, що зберігаються, тригерів, які визначаються користувачем статистичних обчислень і обумовлених користувачем типів.
Обмеження дозволяють задати метод, за допомогою якого компонент СУБД Database Engine автоматично забезпечує цілісність бази даних. Обмеження задають правила допустимості певних значень в стовпцях і являють собою стандартний механізм забезпечення цілісності. Рекомендується використовувати обмеження, а не тригери, правила і значення за замовчуванням. Оптимізатор запитів також використовує визначення обмежень для побудови високопродуктивних планів виконання запитів.
Правила – ще один спеціальний механізм, призначений для забезпечення цілісності бази даних, по функціональності нагадують деякі типи обмежень. Microsoft відзначає, що при відповідній можливості використання обмежень по ряду причин краще і, можливо, в майбутній версії ця можливість буде видалена.
Значення за замовчуванням визначають, якими значеннями заповнювати стовпець, якщо при вставці рядка для цього стовпця значення не вказано. Значення за замовчуванням можуть бути будь-яким виразом, результат якого – константа, наприклад власне константою, вбудованою функцією або математичним виразом.
Лекція 7:
Поняття транзакції. Неявні і явні транзакції. Рівні ізольованості транзакцій в MS SQL Server 2008.
Поняття транзакції. Неявні і явні транзакції.
Транзакція – логічна одиниця роботи в базі даних і так само одиниця відновлення інформації при збої СУБД. При фіксації змін в базі даних гарантується збереження або всіх змін, або жодного. Більш того, виконуються всі правила і перевірки, що забезпечують цілісність даних.
Транзакції бази даних володіють властивостями, скорочено званими ACID (Atomicity, Consistency, Isolation, Durability).
Неподільність (Atomicity). Транзакція або виконується повністю, або не виконується.
Узгодженість (Consistency). Транзакція переводить базу даних з одного узгодженого стану в інше.
Ізольованість (Isolation). Результати транзакції стають доступні для інших транзакцій тільки після її фіксації.
Тривалість (Durability). Після фіксації транзакції зміни стають постійними.
Всі команди, що виконуються користувачами на сервері, виробляються в тілі транзакцій. Однак існує два підходи до вказівкою меж транзакцій в потоці команд – явні і неявні транзакції.
Явні транзакції. За замовчуванням, кожна команда виконується як окрема транзакція. Користувач може об’єднати кілька команд в одну транзакцію, явно вказавши її початок і кінець.
Неявні транзакції. Не існує оператора початку транзакції. Транзакція починається з початком сеансу роботи з БД. Завершується транзакція при наступних подіях:
Явно виконаний оператор завершення транзакції – rollback або commit
Оператор DDL
Завершення сеансу.
Після закінчення транзакції одразу неявно починається нова транзакція.
Рівні ізольованості транзакцій, відмінності реалізації Oracle від інших СУБД
Проблеми організації паралельної роботи:
1. Проблема втраченого поновлення.
[ Cкачайте файл, чтобы посмотреть ссылку ]
2. Проблема залежності від незафіксованих результатів.
[ Cкачайте файл, чтобы посмотреть ссылку ]
3. Непогоджена обробка даних
[ Cкачайте файл, чтобы посмотреть ссылку ]
Відповідно визначають чотири сценарії взаємовпливу кількох транзакцій з точки зору обробки одних і тих же даних.
Брудне читання (dirty read). Допускається читання незафіксованих ( "брудних") даних. При цьому порушується як цілісність даних, так і вимоги зовнішнього ключа, а вимоги унікальності ігноруються.
неповторність при читанні (non-REPEATABLE READ). Це означає, що якщо рядок читається в момент часу T1, а потім перечитується в момент часу T2, то за цей період вона може змінитися. Рядок може зникнути, може бути оновлена і так далі.
Читання фантомів (phantom read). Це означає, що якщо виконати запит в момент часу T1, а потім виконати його повторно в момент часу Т2, в базі даних можуть з’явитися додаткові рядки, що впливають на результати. Від неповторності при читанні це явище відрізняється тим, що прочитані дані не змінилися, але критеріям запиту стало задовольняти більше даних, ніж раніше.
Вводиться чотири рівні ізольованості транзакцій, що характеризуються ступенем взаємовпливу кількох транзакцій, що обробляють одні й ті ж дані.
[ Cкачайте файл, чтобы посмотреть ссылку ]
Особливості реалізації транзакцій в Oracle і MS Sql Server
Загальні оператори управління транзакціями
COMMIT (COMMIT WORK). Оператор COMMIT завершує транзакцію і робить будь-які виконані в ній зміни постійними (тривалими). У розподілених транзакцій використовуються розширення оператора COMMIT. Ці розширення дозволяють помітити оператор COMMIT (точніше, позначити транзакцію), задавши для нього коментар, а також примусово зафіксувати сумнівну розподілену транзакцію.
ROLLBACK (ROLLBACK WORK). Простий оператор відкату завершує транзакцію і скасовує всі виконані в ній і незафіксовані зміни. Для цього він читає інформацію з сегментів відкоту і відновлює блоки даних в стан, в якому вони перебували до початку транзакції.
SAVEPOINT. Оператор SAVEPOINT дозволяє створити в транзакції "мітку", або точку збереження. В одній транзакції можна виконувати оператор SAVEPOINT кілька разів, встановлюючи кілька точок збереження.
ROLLBACK TO <точка збереження>. Цей оператор використовується спільно з представленим вище оператором SAVEPOINT. Транзакцію можна відкотити до зазначеної точки збереження, чи не скасовуючи всі зроблені до неї зміни.
SET TRANSACTION. Цей оператор дозволяє встановлювати атрибути транзакції, такі як рівень ізольованості і то, чи буде вона використовуватися тільки для читання даних або для читання і запису. Цей оператор також дозволяє прив’язати транзакцію до певного сегмента відкату.
Oracle
1. Неявні транзакції. Транзакція автоматично начитається або з початку сеансу або з моменту закінчення попередньої транзакції.
2. Типи транзакцій – Read Write, Read Only. Транзакція Read Only еквівалентна при читанні рівню ізольованості SERIALIZABLE. Така транзакція бачить тільки зміни, зафіксовані на момент її початку, але в цьому режимі не дозволена вставка, зміна і видалення даних (інші сеанси можуть змінювати дані, але транзакція тільки для читання – немає).
3. Рівні ізольованості – Read Committed, Serializable
4. Механізм багатоверсійності. Основні характеристики
1) Узгодженість з читання для запитів. Запити видають узгоджені результати на момент початку їх виконання. Змінні дані містяться в область сегмента відкату.
2) Неблоковані запити. Запити, які змінюють дані, не блокують запити, які читають дані, і читають запити не блокують змінюють, як це буває в інших СУБД.
5. Оператори управління транзакціями
o SET TRANSACTION
o COMMIT, ROLLBACK
o SAVEPOINT
MS Sql Server
1. Явні транзакції. Кожен оператор виконується в своїй транзакції, якщо він не знаходиться в блоці begin tran – commit (rollback)
2. Наявність вкладених транзакцій. приклад
3. begin tran
4. ............
5. begin tran
6. .................
7. commit (rollback)
8. ................
      commit (rollback)
Підтвердження вкладеної транзакції ні на що не впливає. Відкат вкладеної транзакції відкочується внутрішньою транзакцією.
9. Оператори управління транзакціями
1. SET TRANSACTION
2. BEGIN TRANSACTION
3. COMMIT, ROLLBACK
4. SAVEPOINT

Лекція 8:
Реплікація даних. Види і властивості реплікації.
Однією з основних характеристик сховища даних є модель його несуперечності, в якій визначаються правила, які необхідно дотримуватися, щоб сховище повертало в різних процесах правильні результати. Виділяють наступні моделі несуперечності [1]: сувора, послідовна, причинна, FIFO, слабка, вільна і по елементна. Розглядається реплікативний аспект послідовної, слабкою і FIFO моделей несуперечності. Цей вибір обумовлений тим, що перші дві моделі забезпечують глобальну серіалізацію операцій, а остання – досить легко можна реалізувати і є менш жорсткою, ніж перші дві. В [1] наведено визначення всіх перерахованих вище моделей несуперечності, тут же наводяться визначення тільки розглянутих моделей, необхідні для подальшого викладу.
Послідовна несуперечливість визначається наступним правилом:
Результат будь-якої дії такий же, як якщо б операції (читання і запису) всіх процесів в сховище даних виконувалися б в деякому послідовному порядку, причому операції кожного окремого процесу виконувалися б в деякому послідовному порядку, встановленому його програмою.
Несуперечливість FIFO визначається наступним правилом:
Операції записи, які здійснюються одиничним процесом, спостерігаються усіма іншими процесами в тому порядку, в якому вони здійснюються, але операції записи, що відбуваються в різних процесах, можуть спостерігатися різними процесами в різному порядку.
слабка несуперечливість
Для визначення слабкої несуперечності вводиться поняття змінної синхронізації. Мінлива синхронізації (S) має асоційований з нею набір реплікаційних даних і дозволяє виконувати над собою єдину операцію synchronize (S). В ході виконання цієї операції зміни зроблені процесом в локальній копії даних поширюються на всі інші копії даних, асоційовані зі змінною синхронізації. Також в ході цієї операції локальна копія оновлюється даними з інших копій.
Модель слабкою несуперечності має три властивості:
Доступ до змінних синхронізації, асоційованими з сховищем даних, здійснюється на умовах послідовності й несуперечності.
З змінної синхронізації не може бути проведена жодна операція до повного і повсюдного завершення попередніх їй операцій читання і запису над елементами даних.
З елементами даних не може бути проведена жодна операція до повного завершення всіх операцій зі змінними синхронізації.
Протокол несуперечності являє собою конкретну реалізацію відповідної моделі. Прийнято виділяти такі групи протоколів несуперечності [1]: на базі первинної копії, реплікаційного запису, узгодження кешів.
Протоколи на базі первинної копії, що мають на увазі реплікацію даних
Всі протоколи на базі первинної копії мають на увазі наявність для кожного елемента даних Х, асоційованого з ним первинного елемента даних, який відповідає за координацію операцій записи. В [1] виділяється два протоколи підтримують реплікацію:
Протокол первинного архівування з видаленим записом
Опис протоколу:
[ Cкачайте файл, чтобы посмотреть картинку ]
Розшифровка позначень:
W1 – запит на запис
W2 – Пересилання запрошення на сервер
W3 – сигнал на оновлення резервних копій
W4 – підтвердження виконання поновлення
W5 – підтвердження виконання записи
R1 – запит на читання
R2 – відповідь для читання
При реалізації цього протоколу необхідно гарантувати, що в кожен момент часу тільки один вузол має доступ до первинної копії, тим самим, маючи можливість змінювати дані. Існує асинхронний варіант, при якому підтвердження про виконання записи надсилається відразу після поновлення первинної копії (не чекаючи оновлення всіх копій). Це підвищує продуктивність операції запису, однак вимагає додаткових дій для забезпечення: гарантованого оновлення всіх реплік (захист від збоїв при поширенні) і узгодженого читання для вузла, який ініціював оновлення (він не повинен мати можливість вважати значення, який мав елемент даних до запису). У разі якщо всі первинні копії знаходяться на одному вузлі, маємо реалізацію послідовної несуперечності, інакше не роблячи додаткових заходів можна говорити тільки про несуперечності FIFO.
Протокол первинного архівування з локальної записом
Опис протоколу:
[ Cкачайте файл, чтобы посмотреть картинку ]
Розшифровка позначень:
W1 – запит на запис
W2 – переміщення елемента даних х на новий первинний сервер
W3 – підтвердження завершення запису
W4 – сигнал на оновлення резервних копій
W5 – підтвердження оновлення
R1 – запит на читання
R2 – відповідь для читання
У протоколі мається на увазі асинхронне оновлення інших копій. Тут також необхідно вживати додаткових заходів, щоб гарантувати оновлення інших реплік, однак проблеми узгодженого читання для вузла, який ініціював оновлення, тут не виникає. Без додаткових заходів протокол реалізує FIFO несуперечливість, реалізувавши повністю впорядковану групову розсилку (за допомогою відміток часу Лампорта) [1], можна отримати реалізацію послідовно й несуперечливо. Оскільки в протоколі допускається переміщення первинної копії то необхідно вирішити завдання пошуку вузла, що містить первинну копію і зміни власника.
Приклад вирішення завдань пошуку і зміни власника первинної копії
У СУБД Oracle існує метод реплікації даних, що запобігає виникненню конфліктів [2,3], і який містить рішення двох розглянутих задач. В [2] він визначається як dynamic ownership with token passing (динамічне володіння з перехідним маркером). У цьому методі мається на увазі наявність декількох реплік табличних даних, розташованих на різних вузлах, на кожному з яких встановлена СУБД Oracle. До реплікаційної таблиці додається два стовпці, перший з яких містить ім’я вузла (owner), який володіє рядком даних, а другий номер версії рядки даних (epoch). Стовпець epoch використовується для запобігання конфліктів упорядкування при асинхронної розсилці змін.
Алгоритм пошуку первинної копії
Пошук починається з локально вузла. Зчитується значення стовпця owner для заданої рядки даних, ідентифікованої своїм ключем. Якщо значення owner збігається з ім’ям локального вузла (того на якому здійснюється читання), то вузол є власником первинної копії і пошук закінчується. Якщо не збігається, то зчитується значення з рядка, що знаходиться на вузлі, ім’я якого було розраховано на попередньому етапі. Цей процес триває до тих пора не буде знайдений вузол власник.
Алгоритм зміни власника первинної копії
Передбачається, що власник був знайдений за допомогою попереднього алгоритму. Рядок, власник якої змінюється, блокується на вузлі поточного власника. На обох вузлах змінюються значення owner і epoch. Owner змінюється на ім’я вузла, який ініціював зміну власника, а epoch збільшується на одиницю. Після цього решти вузлів асинхронно розсилаються нові значення owner і epoch. Такий алгоритм гарантує, що в кожен момент часу тільки один вузол вважає себе власником рядки.
Протоколи реплікаційних записів
У протоколах реплікаційні записи операції записи можуть здійснюватися на декількох репліках, а не на одній, як у випадку протоколів на базі первинної копії. Існують дві основні різновиди, що розглядаються нижче.
Активна реплікація
Активна реплікація увазі можливість поновлення довільній репліки з подальшою розсилкою оновлень іншим реплік (за допомогою команд поновлення або самих оновлених даних). Для того щоб за допомогою активної реплікації можна було реалізувати модель послідовної несуперечності, необхідно гарантувати однакову послідовність виконання всіх операцій запису на всіх машинах. Це можна забезпечити за допомогою впорядкованої групового розсилання, побудованої за допомогою відміток часу Лапорта, або за допомогою виділення спеціального вузла, який буде впорядковувати всі операції запису, за рахунок присвоєння їм послідовного унікального ідентифікатора. Останнє рішення, однак, наближає активну реплікацію до протоколів на базі первинної копії. Також можливо треба буде розв’язати проблему реплікованих звернень, сенс якої полягає в наступному: якщо об’єкт А звертається до реплікаційного об’єкту В, який при цьому звертається до об’єкту С, то об’єкт З отримає кілька звернень замість одного.
Протоколи кворуму
Основна ідея, що лежить в основі протоколів кворуму полягає в тому, щоб запитувати дозвіл на проведення операцій читання і запису у кількох серверів, що утворюють кворум. Існують кворум записи і кворум читання. Ці Кворуми треба зібрати перед проведенням відповідних операцій. При цьому з кожною операцією запису одних і тих же даних зіставляється послідовно зростаючий номер версії. Нехай розділяється ресурс має N реплік, тоді кворум читання Nr (кількість реплік, до яких виконується запит на читання) і кворум записи Nw (кількість реплік, в яке здійснюється запис) визначаються з наступних двох умов:
Nr + Nw> N
Nw> N / 2
Сенс цих обмежень полягає в наступному: перше обмеження гарантує, що при опитуванні Nr серверів, хоча б один з них містить останню версію запитуваних даних, друге обмеження усуває конфлікт подвійного запису, тобто робить неможливих існування розрізняються копій одних і тих же даних, що мають однакову версію. У граничному випадку, коли Nr = 1 Nw = N, всі операції читання можуть бути здійснені локально, проте операція оновлення повинна бути проведена на всіх репліках.
Зауваження з приводу реалізації вільної несуперечності
Протоколи на базі первинної копії погано підходять для реалізації вільної несуперечності. Це пояснюється тим, що в них операція записи, автоматично породжує виконання синхронізації реплік, тоді як при вільної несуперечності розуміється незалежне виконання операцій синхронізації. Протоколи реплікаційних записів (активна реплікація) куди краще підходять для реалізації даної моделі. Для реалізації активної реплікації потрібна повністю впорядкована групова розсилка. Оскільки в моделі слабкої несуперечності мається на увазі доступ до змінних синхронізації згідно послідовної несуперечності, то впорядкована групова розсилка може бути використана для організації доступу до змінних синхронізації.
Завдання отримання нової несуперечливої репліки
Розглядається розподілене сховище даних (РГД), що складаються з N вузлів, кожен з яких містить репліки даних. Стоїть завдання отримання несуперечливої репліки для нового N + 1 вузла.
Існує два різних підходи до вирішення цього завдання:
1. Переклад розподіленого сховища даних в стан, в якому виконання операцій зміни даних заборонено, з подальшим копіюванням всіх необхідних даних в нову репліку
2. Отримання нової репліки без припинення виконання операцій зміни, при цьому розподілене сховище даних продовжує функціонувати в звичайному режимі
Алгоритм, який ілюструє 1–ий підхід
Вузол, який ініціює операцію з переведення сховища даних в особливий стан, посилає всім іншим вузлам повідомлення про заборону ініціювати нові зміни. У відповідь на це повідомлення кожен з вузлів, позначає всі повідомлення, ініціатором яких він є, і які вже знаходяться в його локальної черзі, але ще не оброблені. Далі кожен вузол продовжує обробляти всі вступники від інших вузлів повідомлення і свої помічені повідомлення. Після того як буде оброблено останнім позначене повідомлення, кожен вузол посилає повідомлення вузлу ініціатору про завершення виконання своїх операцій. Після того як вузол ініціатор отримає такі повідомлення від усіх вузлів, РХД буде знаходитися в спеціальному стані і можна починати операції копіювання для отримання нової репліки.
Алгоритм отримання глобального стану системи
В [1] наводиться алгоритм отримання глобального стану. Вузол, який ініціює отримання глобального стану системи, виконує локальне копіювання і посилає всім іншим вузлам запит на проведення операції отримання глобального стану. Кожен вузол, отримавши такий запит, робить одне з двох:
1. Якщо запит отримано вперше, то він записує своє локальне стан і пересилає запит всім іншим вузлам. Після цього він починає протоколювати всі вхідні повідомлення від усіх вузлів
2. Інакше він зберігає список всіх повідомлень отриманих від вузла джерела (вузол, від якого йому прийшов запит) за час протоколювання повідомлень і перестає протоколювати повідомлення цього вузла. Після того як будуть отримані повідомлення від усіх вузлів, вузлу, який ініціював отримання глобального стану, надсилається записане локальне стан і всі збережені списки повідомлень.
На підставі алгоритму отримання глобального стану системи можна запропонувати алгоритм отримання нової репліки для РХД, в якому всі зміни виконуються за допомогою розподілених транзакцій, без призупинення виконання операцій зміни.
Алгоритм, який ілюструє 2–ий підхід
Вузол, для якого виходить нова репліка (вузол N), втягується в виконання розподілених транзакцій. Для кожного запиту на проведення розподіленої транзакції він підтверджує виконання своєї частини, реально не виконуючи ніяких дій. Далі він розсилає всім вузлам повідомлення на отримання глобального стану. Кожен вузол, отримавши це повідомлення, виконує ті ж дії, що і в алгоритмі 2. Завершивши формування свій частині глобального стану, кожен з вузлів посилає його вузлу N. Вузол N отримає, таким чином, два повідомлення від кожного з інших вузлів: 1 та після того як вузол збереже своє локальне стан (надсилається при 1–му дії за алгоритмом 2) і 2–е, що містить частину глобального стану (надсилається при 2–му дії за алгоритмом 2). Після отримання 1–ого повідомлення від деякого вузла M, вузол N починає протоколювати всі наступні повідомлення від цього вузла, до тих пір поки не отримає повідомлення 2 від всіх вузлів. Після цього вузол N має в своєму розпорядженні глобальний стан і список повідомлень від кожного з вузлів, які були послані вузлу N, після збереження ними свого локально стану. Цих даних достатньо, щоб отримати нову несуперечливу репліку.
Якщо прийняти додаткові припущення про РХД, наприклад, що всі репліки містять одні й ті ж дані або що всі зміни здійснюються за допомогою розподілених транзакцій, то можна модифікувати алгоритм 3, підвищивши його ефективність за рахунок зменшення кількості повідомлень, що пересилаються. Це є предметом подальшої розробки.
В результаті подальшої роботи передбачається адаптувати розглянуті в статті алгоритми для розподіленого сховища даних, все репліки якого містять одні й ті ж дані, всі оновлення одночасно здійснюються на всіх вузлах за допомогою розподілених транзакцій. За основу реалізації передбачається взяти протокол первинного архівування з видаленим записом. Первинні копії всіх даних передбачається розмістити на сервері БД, що працює під управлінням СУБД Oracle.

Лекція 9:
Внутрішня мова СУБД. Характеристики T–SQL.
Практично кожна СУБД має в своєму складі процедурне розширення мови SQL. Ці мови використовуються для реалізації бізнес-логіки і додаткових перевірок цілісності на рівні сервера. Програмні модулі, написані на цих мовах, зберігаються в СУБД і виконуються спеціальним компонентом безпосередньо в ядрі СУБД. Синтаксис таких мов розроблений для максимально простою та зручною інтеграції з SQL. Модулі процедурного розширення SQL можуть бути одного з наступних типів:
1. Процедури, що зберігаються, пакети, функції
2. Тригери
3. Безіменні блоки
SQL Server. Процедурне розширення – Transact-SQL (T-SQL). Володіє основними можливостями. До версії 2005 була відсутня обробка винятків.
Основні характеристики T-SQL:
Повний діапазон типів даних
Явно визначається структура коду – блоки даних, процедури і т.д.
Оператори управління потоком команд – умовні, цикли і т.д.
Обробники винятків
Тісна інтеграція з SQL – безпосередній виклик команд SQL з процедурного коду
Основні об’єкти. Збережені процедури і функції
Процедура або функція – це підпрограма, що складається з SQL операторів і команд процедурного мови. Процедура і функція може:
Утримувати параметри (аргументи);
Викликати інші процедури;
Повертати свій статус викликає процедурі або пакету, який вказує на успішне закінчення або помилку, і в разі помилки на її причину;
Повертати значення параметрів викликає процедурі або пакету;
Виконується завжди на стороні сервера.
Функція крім того повертає результат через своє ім’я.
Збережені процедури і функції значно збільшують потужність, ефективність і гнучкість мови SQL і значно прискорюють виконання SQL-операторів і пакетів.
Збережені процедури здійснюються командою create procedure. Функції здійснюються командою – create function. Для виконання процедури, як системної, так і певної користувачем, використовується команда execute (виконати). Можна також просто вказати назву процедури, що, якщо воно є першим словом в операторі або пакеті.
Процедура або функція має дві частини:
Специфікація, яка оголошує процедуру або функцію і складається з такої інформації:
o Імені процедури
o Імен і типів даних аргументів, якщо є
o Крім цього, ТІЛЬКИ для функцій – типу даних повертається
Тіло, яке визначає процедуру або функцію. Тіло процедури складається з блоку T–SQL (який містить пропозиції SQL і процедурного розширення).
Основні об’єкти. Тригери
Тригер – це процедура, що зберігається спеціального виду, яка запускається при виникненні якої-небудь події, зазвичай зміни даних в таблиці. Зокрема, тригери допомагають зберегти кількість посилань цілісність даних користувача, перевіряючи їх узгодженість в логічно зв’язаних таблицях. Основною перевагою тригерів є те, що вони викликаються автоматично. Вони будуть працювати незалежно від причини, яка викликала модифікацію даних, як, наприклад, після введення даних клерком, так і при виконанні деякої прикладної процедури. Тригер може бути пов’язаний з одним або декількома операторами модифікації, такими як update, insert або delete.

Лекція 10:
Збережені процедури і функції. Типи параметрів, синтаксис опису формальних параметрів
SQL Server
Процедура – це підпрограма, що складається з SQL операторів і команд T-SQL. Процедура зберігається на сервері і виконується за командою користувача або викликається з блоку T–SQL. План виконання процедури готується під час запуску процедури, тому власне виконання процедури відбувається дуже швидко. Процедура може:
Утримувати параметри (аргументи);
Викликати інші процедури;
Повертати свій статус викликає процедурі або модулю T_SQL, який вказує на успішне закінчення або помилку, і в разі помилки на її причину;
Повертати значення параметрів викликає процедурі або модулю T-SQL;
Синтаксис для створення процедури:
create procedure [власник.] названіе_процедури [; номер] [
[(] @ Названіе_параметра тип_даних [= default] [output]
[@ Названіе_параметра тип_даних [= default] [output]] ... [)]] [with
recompile]
as sql_оператори
Оператор execute:
[Execute] [return_status =]
[[[сервер.]база_данных.]владелец.]название_процедуры[;номер]
[[@ Названіе_параметра =] значення |
[@ Названіе_параметра =] @ змінна [output]
[, [@ Названіе_параметра =] значення |
[@ Названіе_параметра =] @ змінна [output] ...]]
[With recompile]
Параметри
Параметр – це аргумент процедури, що. Один або кілька параметрів можуть бути оголошені в операторі створення процедури. Значення кожного параметра, оголошеного в операторі create procedure, має зазначатися користувачем в момент виклику процедури.
Назв параметрів повинен передувати символ "@", а самі ці назви повинні відповідати правилам, встановленим для ідентифікаторів. Для всіх параметрів повинен бути вказаний системний або призначений для користувача тип даних, і якщо необхідно довжина цього типу даних. Назви параметрів є локальними по відношенню до їх містить процедурі; такі ж назви можна використовувати для параметрів в іншій процедурі.
В операторі create procedure для параметра можна вказати значення, яке приймається за замовчуванням. Це значення, яке може бути будь-який константою, використовується як аргумент процедури, якщо для цього параметра не було вказано жодного значення.
CREATE proc dbo.tran_Begin / *
 * Ініціалізація транзакції
 * Якщо процедура виконується в транзакції, то створюється savepoint
 * Інакше ініціалізується транзакція
 * На виході передається null для транзакції і ім’я точки збереження для savepoint
 * /
(trName DObjectName output,explicitSavepointNameFlag DLogical = 0)
as
declared Datetime
begin
– Return 0

[email protected]@trancount = 0
begin
selecttrName = null
begin transaction
end
else
begin
– Якщо не задано ім’я і не встановлено прапор використання переданого імені, то генерується ім’я
ifexplicitSavepointNameFlag = 0 ortrName is null
begin
selectd = getdate ()
selecttrName = tr _’ + ISNULL (convert (varchar,@@nestlevel), ) + _’ + ISNULL (convert (varchar (50),
rand (datepart (mm,d) * 100000 + datepart (ss,d) * 1000 + datepart (ms,d))), )
end
save trantrName
end

[email protected]@error <> 0
begin
– Помилка створення транзакції
return 5
end

return 0
end

CREATE proc dbo.tran_Commit / *
 * Підтвердження транзакції
 * Працює в парі з tran_Begin
 * На вхід передається ім’я точки збереження (транзакції), повернене tran_Begin
 * Якщо виклик йде з транзакції іtrName одно null, то виконується commit,
 * Інакше нічого не робиться
 * /
(trName DObjectName)
as
begin
[email protected]@trancount> 0 andtrName is null
begin
commit

[email protected]@error <> 0
begin
– Помилка підтвердження транзакції
return 6
end
end

return 0
end

CREATE proc dbo.tran_Rollback / *
 * Відкат транзакції
 * Працює в парі з tran_Begin
 * На вхід передається ім’я точки збереження (транзакції), повернене tran_Begin
 * Якщо виклик йде з транзакції іtrName одно null, то виконується відкат всій транзакції,
 * Інакше виконується відкат до точки збереженняtrName
 * /
(trName DObjectName)
as
begin
[email protected]@trancount> 0
begin
iftrName is null
rollback tran
else
rollback trantrName

[email protected]@error <> 0
begin
– Помилка відкату транзакції
return 7
end
end

return 0
end
Лістинг 10.1.
Повернення результатів
Збережені процедури повідомляють свій "статус повернення", який вказує, чи була виконана процедура повністю, чи ні, а також причини невдачі. Це значення може зберігатися у змінній, яка передається процедурі при її виклику, і використовуватися в наступних операторах Transact-SQL. Інший спосіб повернення інформації з збережених процедур полягає в поверненні значень через вихідні параметри. Параметри, визначені як вихідні, в операторі create procedure (створити процедуру) або execute (виконати) використовуються для повернення значень в місце виклику процедури. Потім за допомогою умовних операторів можна перевірити значення, яке повертається.
Код повернення і вихідні параметри дозволяють розділити збережені процедури на модулі. Група SQL операторів, які використовуються декількома збереженими процедурами, можуть бути об’єднані в одну процедуру, яка повідомляє свій статус виконання або значення своїх параметрів викликає процедурі. Наприклад, багато системних процедури, що поставляються з SQL сервером, звертаються до процедури, яка перевіряє чи є зазначені параметри правильними ідентифікаторами.
Якщо в операторах create procedure і execute вказується опція output в назві параметра, то процедура повертає значення цього параметра викликає об’єкту. Цим об’єктом може бути SQL пакет або інша процедура, що зберігається, які використовують повернені значення в своїй подальшій роботі. Якщо повертаються параметри використовуються в операторі execute, який є частиною пакета, то значення, що повертаються параметрів разом з заголовком виводяться на екран перед виконанням наступних операторів пакета.
declaretranName DObjectName
declareretCode integer
begin

execute tran_BegintranName output

selecttranName
Лекція 11:
Тригери. Основні поняття. Типи тригерів. Загальна схема активізації тригерів
Тригер – це виконуваний модуль, прив’язаний до об’єкта бази даних і події, пов’язаної з цим об’єктом. Тригер викликається неявно при виникненні події над цим об’єктом. Тригери мають наступні характеристики:
Тип тригера – DDL або DML
Об’єкт – таблиця, VIEW, системний об’єкт для DDL тригерів
Подія – insert, update, delete для таблиці і DML, instead of для VIEW або системна подія для DDL тригерів.
Спосіб активації – для всього оператора або для кожного рядка
Час активації – до або після виконання оператора.
Тригери в T–SQL по функціональності біднішими тригерів в Oracle. У SQL Server існують тільки after або instead of тригери, що викликаються для всього оператора.
Тригери SQL Server
Створення тригерів
create trigger trg
on my_table
for insert, update, delete
as
select "this is trigger"
Синтаксис команди створення тригера create trigger
create trigger [власник.] названіе_тріггера
  on [власник.] названіе_табліци
  for {insert, update, delete}
  as SQL_оператори

create trigger [власник.] названіе_тріггера
  on [власник.] названіе_табліци
  for {insert, update}
  as
  [If update (названіе_столбца) [{and | or}
    update (названіе_столбца)] ...]
       SQL_оператори
  [If update (названіе_столбца) [{and | or}
     update (названіе_столбца)] ...
        SQL_оператори] ...

CREATE trigger dbo.TD_Inscribe on Inscribe
for DELETE
as
begin
delete PP_S_ImageObject
where PP_S_ImageObject.ImageObjectID in
(Select deleted.PhotoID from deleted)

delete from
ImageObject
where
ImageObject.ImageObjectID in
(Select deleted.PhotoID from deleted)
end
видалення тригерів
Команда видалення тригера drop trigger має наступний вигляд:
drop trigger [власник.] названіе_тріггера
     [, [Власник.] Названіе_тріггера] ...
Таблиці INSERTED і DELETED
Коли викликаються тригери використовуються дві спеціальні таблиці: таблиця видалення (deleted table) і таблиця додавання (inserted table). Вони використовуються для перевірки операторів модифікації даних і створення умов для роботи тригерів. Користувач не може безпосередньо змінювати дані в цих таблицях, але може використовувати що знаходиться в них інформацію для перевірки наслідків виконання операторів insert, update або delete.
У таблиці deleted зберігаються копії рядків, які видаляються операторами update або delete. В процесі виконання цих операторів рядки видаляються з критичною таблиці і поміщаються в таблицю видалення. Зазвичай тригерна таблиця і таблиця видалення не мають спільних рядків.
У таблиці inserted зберігаються копії рядків, які вставляються операторами insert або update. В процесі виконання цих операторів нові рядки вставляються в таблицю додавання і тригерну таблицю одночасно. Таким чином, таблиця додавання завжди містить копії нових рядків, які були додані в тригерну таблицю.
[ Cкачайте файл, чтобы посмотреть картинку ]
CREATE trigger dbo.TU_Inscribe on Inscribe
for UPDATE
as
begin
if exists (
select
1
from
deleted, inserted
where
deleted.IdentifyDocumentID = inserted.IdentifyDocumentID
and deleted.InscribeID = inserted.InscribeID and
deleted.PhotoID is not null and inserted.PhotoID is null
)
begin
delete PP_S_ImageObject
where
PP_S_ImageObject.ImageObjectID in
(select
deleted.PhotoID
from
deleted, inserted
where
deleted.IdentifyDocumentID = inserted.IdentifyDocumentID
and deleted.InscribeID = inserted.InscribeID and
deleted.PhotoID is not null and inserted.PhotoID is null
)

delete
ImageObject
from
ImageObject
where
ImageObject.ImageObjectID in
(select
deleted.PhotoID
from
deleted, inserted
where
deleted.IdentifyDocumentID = inserted.IdentifyDocumentID
and deleted.InscribeID = inserted.InscribeID and
deleted.PhotoID is not null and
inserted.PhotoID is null
)
end
end
15

Приложенные файлы

  • doc 14748035
    Размер файла: 748 kB Загрузок: 1

Добавить комментарий