18120

Транзакції в мові SQL

Лекция

Информатика, кибернетика и программирование

Тема 5: Транзакції в мові SQL Що таке транзакція Транзакція transaction може бути визначена як логічна послідовність операцій над даними яка розглядається як окрема цілісна частина роботи. У транзакції робляться або всі зміни або жодної. Транзакції підтримують ACIDвластиво

Украинкский

2013-07-06

88.5 KB

7 чел.


Тема 5: Транзакції в мові SQL

Що таке транзакція?

Транзакція (transaction) може бути визначена як логічна послідовність операцій над даними, яка розглядається як окрема цілісна частина роботи. У транзакції робляться або всі зміни, або жодної. Транзакції підтримують ACID-властивості: атомарність (atomicity), несуперечливість (consistency), ізольованість (isolation) і довговічність (durability).

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

– Несуперечливість гарантує, що до моменту завершення транзакції БД буде перетворена з одного коректного стану в інший.

– Ізольованість гарантує, що паралельні транзакції не бачать часткових і незавершених (uncommitted) змін, зроблених одна одною.

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

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

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

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

Де живуть транзакції

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

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

Приклад транзакції

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

Begin Transaction Account_Transfer

Deduct $500 from Savings Account

If Error Then Roll Back Transaction Account_Transfer

Credit $500 to Credit Card Account

If Error Then Roll Back Transaction Account_Transfer

Commit Transaction Account_Transfer

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

Тепер розглянемо кожну операцію окремо. Команда begin transaction (початок транзакції) створює запис в log-файлі (файлі реєстрації, журналі транзакцій), що свідчить про початок транзакції. Операція update (модифікація) віднімає $500 з ощадного рахунку і реєструється як послідовність змін в сторінках даних. Операція модифікації, що додає $500 на рахунок кредитної картки, записується таким же чином. Після проведення обох операцій модифікації в log-файлі містяться записи про старі і нові значення рахунків. Фінальна операція commit (фіксація) відзначає в log-файлі кінець транзакції. Після цього в log-файлі поміщаються записи всіх змін, зроблених в БД при виконанні операцій переведення. Якщо помилка відбувається під час зміни ощадних рахунків, log-файл використовується для відміни виконаних над ними дій. Якщо відмова системи відбувається після того, як операція записана в log-файл, то за допомогою аналізу записів в log-файлі СУБД може гарантувати, що операція переказу грошей між рахунками цілісна (несуперечлива), а значення правильні.

Велика частина сучасних реляційних БД надають програмістам можливість встановити в межах транзакції маркер (прапорець, покажчик), який називають «savepoint». Savepoint визначає (вказує на) стан (розташування), до якого можна відкотити транзакцію при відміні по якійсь логічній умові частини транзакції. Якщо відкат транзакції назад здійснений до точки, на яку вказує маркер, транзакція все ж таки повинна бути або завершена, або повністю прокручена назад.

Конкурентні транзакції. Рівні ізольованості транзакцій

Конкурентні транзакції – це ті, що здійснюють доступ до одних і тих же даних в один і той же час. Такого роду транзакції часто виникають при паралельній роботі багатьох користувачів з базою даних.

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

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

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

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

Говорять, що транзакція Т2 залежить від транзакції Т1 в історії Н, якщо Т2 прочитує або оновлює об'єкти даних, вже оновлені транзакцією Т1, або якщо Т2 оновлює об'єкти даних, вже прочитані або оновлені Т1.

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

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

Феномени, виділені в SQL-92:

Dirty Reads (брудне читання): зміни, зроблені і незавершені усередині транзакції, можуть читатися іншими транзакціями. В результаті транзакція може прочитати дані, які не існуватимуть після завершення іншої транзакції.

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

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

Приклади проблем, пов'язаних з феноменами:

– P1 (брудне читання) (Dirty Read).

Транзакція T1 модифікувала вміст елементу даних. Після цього інша транзакція T2 прочитала вміст цього елементу даних, до того як транзакція T1 виконала операцію COMMIT (зафіксувалася) або ROLLBACK (відкотилася). Якщо T1 завершується операцією ROLLBACK, то виходить, що транзакція T2 прочитала реально не існуючі дані.

– P2 (читання, що не повторюється або розмите читання) (Non-repeatable or Fuzzy Read).

Транзакція T1 прочитала вміст елементу даних. Після цього інша транзакція T2 модифікує або видаляє цей елемент даних і фіксується. Якщо T1 після цього спробує прочитати вміст цього елементу даних знову, то вона набуде іншого значення або виявить, що елемент даних більше не існує.

– P3 (Фантом) (Phantom).

Транзакція T1 прочитала вміст декількох елементів даних, що відповідають деякому предикату <search condition>. Після цього, транзакція T2 змінює елементи даних, що відповідає цьому предикату, і фіксується. Наприклад, значення елементів даних змінилися так, що умова <search condition> для них перестала виконуватися або ці об'єкти даних просто видалені, а деякі об'єкти даних, що раніше не потрапляли у вибірку, тепер в неї потрапляють (наприклад, додалися нові записи або модифікувалися значення існуючих записів так, що для них тепер <search condition> виконується). Якщо транзакція T1 повторить читання з тим же предикатом <search condition>, то одержить вже інший набір даних, відмінний від одержаного на початку.

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

Визначення ізольованості транзакцій. Транзакція T ізольована від інших транзакцій, якщо:

(0) T не змінює "брудні дані" інших транзакцій.

(1) Зміни даних транзакції T не можуть бути прочитані або змінені іншими транзакціями до виконання операції завершення транзакції Т (COMMIT чи ROLLBACK).

(2) T не прочитує "брудних даних" інших транзакцій.

(3) Інші транзакції не оновлюють які-небудь дані, прочитані Т, до тих пір, поки Т не завершиться (COMMIT чи ROLLBACK).

Твердження 0 і 1 виключають втрачені оновлення, твердження 2 ізолює транзакцію від брудного читання, твердження 3 запобігає неповторюваному читанню і фантомам. Якщо всі транзакції задовольняють умовам (0)-(3), то мають місце наступні властивості:

  •  Несуперечність вхідних даних. Кожна транзакція прочитує несуперечливий стан даних.
  •  Ізольоване виконання. Будь-яка послідовність виконання операцій множини транзакцій М еквівалентна деякій серійній (послідовної) історії. Це означає, що будь-яка історія еквівалентна історії без паралелізму, а кожна логічна підмножина історії еквівалентно виконанню операцій без аномалій паралелізму.
  •  Збереження змін. Якщо якась транзакція закінчилася виконанням операції ROLLBACK (відкіт), або відбувся збій в системі, що призвів до вимушеного відкоту декількох транзакцій, що не закінчилися, то незафіксовані дані відкоту можуть бути втрачені. Ніякі оновлення або повідомлення зафіксованих (committed) транзакцій не можуть бути втрачені. Таким чином, зберігається логічна несуперечність даних, і виконання перерваних транзакцій може бути відновлено.

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

Повністю сумістити високий рівень паралелізму обробки транзакцій і високий рівень їх ізольованості не вдається. Тому йдуть по шляху ослаблення ізольованості транзакцій на користь підвищення рівня паралелізму.

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

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

Сумісність блокувань регулюється наступною матрицею:

Накладене блокування

Блокування, на яке йде запит

None

Share

eXclusive

None

Да

Да

Да

Share

Да

Да

Ні

eXclusive

Да

Ні

Ні

Стандарт SQL-92 специфікує рівні ізольованості транзакцій, які надають програмісту можливість визначати різні типи поведінки в конкурентній транзакції. Рівень ізольованості транзакцій (transaction isolation level) – рівень, на якому транзакція може визначити inconsistent (суперечливі, фактично вже змінені в результаті операцій всередині транзакції) дані, що вказує на ступінь ізольованості однієї транзакції від іншої (якщо просто, як транзакція взаємодіє з іншими, конкуруючими транзакціями). Низький рівень ізольованості збільшує можливість паралельної обробки, але може привести до суперечності даних. І навпаки, вищий рівень ізольованості приводить до частішого блокування результатів.

В стандарті SQL-92 визначені 4 рівні ізольованості транзакцій, які визначаються за допомогою класичного визначення серіалізованості (послідовності) і трьох вищезгаданих феноменів:

Read Uncommitted (читання змін незавершеної транзакції): найнижчий рівень ізольованості, що забезпечує максимальний паралелізм, дозволяючи транзакції виконувати «брудне» читання (dirty read). Dirty Read дозволяє транзакції читати зміни, зроблені іншими транзакціями до їх завершення (uncommitted). Наприклад, якщо транзакції A і B стартували, і поміняли записи, то вони обидві бачать зміни один одного. В InterBase цей режим не підтримується.

Read Committed (читання змін завершеної транзакції): транзакція може читати тільки ті зміни, які були зафіксовані іншими транзакціями. Наприклад, якщо транзакції A і B стартували і поміняли записи, то вони не бачать зміни один одного. Транзакція А побачить зміни транзакції B тільки тоді, коли транзакція B завершиться по commit. Перечитування даних в транзакції може видавати різні результати.

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

Serializable (впорядковане, послідовне): найвищий рівень ізольованості. Транзакції повністю ізольовані один від одного – вони виконуються так, як ніби ніяких інших транзакцій у цей момент не існує або транзакції виконуються так, начебто вони виконуються послідовно. Це найбільш високий зі всіх чотирьох рівнів ізольованості. Паралелізм в даному випадку найнижчий. Можливість зміни даних в процесі виконання транзакції практично неможлива (навіть якщо БД і дозволяє це робити, висока вірогідність отримання «deadlock» - тупикової ситуації, взаємного блокування, що приводить до необхідності перезавантаження не лише програми, а і всієї БД в цілому). Зате високий ступінь цілісності даних і захисту всієї БД. Не підтримується явно в IB, але може бути земульовано.

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

Транзакції  в Interbase/Firebird

При використанні операторів мови SQL для роботи з базою даних для запуску транзакції і задання її характеристик використовується команда SET TRANSACTION. Ось дещо спрощений синтаксис цієї команди:

SET TRANSACTION

  [READ WRITE | READ ONLY] /* режим доступу */

  [WAIT | NO WAIT]         /* режим дозволу блокувань */

[[ISOLATION LEVEL]          /* рівень ізоляції */

  {SNAPSHOT |

   SNAPSHOT TABLE STABILITY |

   READ COMMITTED [{RECORD_VERSION |

                    NO RECORD_VERSION}]]

[RESERVING <речення резервування>]

RESERVING задає необов'язкове резервування таблиць. Синтаксис речення резервування наступний:

<таблиця> [, <таблиця> ...]

 [FOR [SHARED | PROTECTED] {READ | WRITE}]

 [, <речення резервування> ...]

Значенням за змовчанням для транзакції (якщо не задані характеристики в операторі SET TRANSACTION) є:

SET TRANSACTION READ WRITE WAIT SNAPSHOT;

Найпростіша характеристика — режим доступу. READ WRITE дозволяє в рамках даної транзакції читати і змінювати дані бази даних. У разі READ ONLY в контексті даної транзакції допустимі лише операції читання даних.

Найважливіша характеристика транзакції — рівень ізоляції. Далі наведені три існуючі рівні ізоляції транзакції:

  •  READ COMMITTED. Читання підтверджених змін. Транзакція може бачити самі останні зафіксовані зміни бази даних, виконані іншими транзакціями. При цьому рівні ізоляції використовуються ще два взаємовиключні параметри. За змовчанням NO RECORD_VERSION вимагає, щоб було виконане підтвердження всіх змінених іншими транзакціями даних. RECORD_VERSION дозволяє читати саму останню підтверджену версію змін, навіть якщо існують інші непідтверджені версії.
  •  SNAPSHOT. Миттєвий знімок (образ). Значення за умовчанням. Інша назва — повторюване читання (Repeatable Read). Дає стан бази даних на момент старту транзакції. Зміни, виконані іншими транзакціями, в даній транзакції не видно. Природно, транзакція «бачить» всі зміни, виконані в контексті цієї транзакції.
  •  SNAPSHOT TABLE STABILITY. Ізольований образ або упорядковуваний, з можливістю серіалізації (Serializable) образ. Аналогічний рівню SNAPSHOT з тією відмінністю, що іншим транзакціям дозволено читання даних з таблиць даної транзакції, проте вони не можуть вносити в них ніяких змін.

Крім перерахованих вище рівнів ізоляції в SQL-92 є ще один рівень — Read Uncommitted з можливістю брудного читання, або, іншими словами, непідтвердженого читання. В InterBase і Firebird такий рівень ізоляції не підтримується.

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

Техніки роботи з транзакціями

Транзакція може бути «довгою» і «короткою». «Довга» — якщо користувач вручну запускає транзакцію, виконує різні зміни даних і підтверджує або відміняє транзакцію, коли йому заманеться. Це може приводити до блокувань. Приклад «короткої» транзакції — користувач в програмі клацає по кнопці ОК на формі додавання або зміни даних в базі даних, після чого програма викликає метод Insert або Edit (характерно для Delphi) для відповідного набору даних, встановлює значення полів і викликає метод Post, який відправляє зміни в базу даних; транзакція оновлення запускається в момент виклику методу Post; відразу після Post виконується підтвердження транзакції. Як правило, час життя такої короткої транзакції обчислюється долями секунди, що зменшує вірогідність блокувань при розрахованій на багато користувачів роботі з базою даних.

Обробка відмов

Що робить сервер при відмові клієнтської програми?

Менеджер комунікацій системи періодично здійснює опитування «живучості» програми-клієнта. Якщо призначений для користувача процес не виявлений, то виконуються наступні дії:

– визначаються всі з'єднання з сервером, які були відкриті на момент відмови програми (це робить менеджер комунікацій);

– менеджеру транзакцій передається запит про стан транзакцій, які виконувалися по даних з'єднаннях, а також вимога відкоту всіх незавершених транзакцій цих з'єднань;

– у разі виявлення незавершених транзакцій менеджер транзакцій передає запит менеджеру журналу; ініціюється відкіт цих транзакцій;

– після завершення відкоту транзакцій менеджер транзакцій ініціює звільнення всіх структур, що обслуговували з'єднання програми, що відмовила;

– на цьому обробка відмови програми завершується.

Що робить сервер у разі жорсткого збою при наступному старті?

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

При рестарті системи викликається менеджер журналу, і скануються всі структури журналу:

– перевіряються фізична цілісність системного каталогу бази даних і постійного сховища;

– перевіряється наявність незавершених транзакцій на момент відмови системи, ініціюється відкіт операцій таких транзакцій;

– перевіряється наявність завершених транзакцій, результати яких не були занесені в постійне сховище; для успішно завершених транзакцій проводиться повторне виконання операцій по журналу, а для неуспішно завершених - частина відкоту, що залишилася (цим забезпечується узгодженість постійного сховища);

– після того, як сховище даних приведене в коректний стан, звільняються задіяні при рестарті структури журналу;

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

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


 

А также другие работы, которые могут Вас заинтересовать

213. Коммуникационные технологии 538.5 KB
  Обмен информацией производится по каналам передачи информации. Каналы передачи информации могут использовать различные физические принципы. Сетевое программное обеспечение (ПО) и сетевой протокол. Глобальные компьютерные сети. История развития сети интернет.
214. Проектирование комбикормового цеха 740.12 KB
  Характеристики применяемых материалов и изделий, фундаменты и фундаментные балки. Сведения о наружной и внутренней отделке. Организация и технология производства работ. Выбор грузозахватных приспособлений. Определение численного и квалификационного состава бригады для производства каменных работ.
215. Методы замера твердости металлов и их структурный анализ 538.5 KB
  Назначение легирующих элементов и их влияние на свойства стали. Краткие сведения о закалке и отпуске углеродистых сталей. Изучение упрочнения деталей из углеродистых сталей закалкой и последующим отпуском.
216. Исследование и расчет долбежного станка 315 KB
  Понижение класса кинематических пар звеньев. Построение планов скоростей для 12 положений механизма. Приведение масс звеньев механизма и построение графика приведенного момента инерции. Силовой расчет рычажного механизма.
217. Экологическое право. История формирования экологического права России 256.02 KB
  История формирования экологического права России. Право природопользования. Виды прав на природные объекты и ресурсы. Охрана окружающей среды при осуществлении хозяйственной и иной деятельности. Международно-правовой механизм охраны окружающей среды.
218. Образовательный процесс на примере темы искусство Древней Месопотамии 607 KB
  Структурно-методический анализ учебного материала. Анализ учебно-программной документации. Определение обучающих, воспитывающих, развивающих и когнитивных целей. Методы конструирования на основе методического анализа учебного материала.
219. Проектирование механического привода с одноступенчатым редуктором 433 KB
  Расчеты и конструирование одноступенчатого конического зубчатого редуктора, приведены расчеты конических зубчатых передач, валов, шпонок на прочность, геометрия и кинематика зубчатой передачи.
220. Факультативный курс Параметры в геометрии 644 KB
  Общие вопросы организации и проведения факультативных курсов по математике. Анализ школьных учебников по геометрии федерального комплекта. Разработка факультативного курса Параметры в геометрии.
221. Совершенствование политики управления запасами коммерческой организации ОАО Бердский Хлебокомбинат 891.5 KB
  Разработка мероприятий по совершенствованию политики управления запасами для ОАО Бердский Хлебокомбинат. Для достижения этой цели необходимо решить следующие задачи. Материально-производственные запасы как элемент оборотного капитала.