7597

Проектування БД. Загальні поняття

Лекция

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

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

Украинкский

2013-01-26

90 KB

7 чел.

PAGE  6

Проектування БД

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

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

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

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

        В процесі проектування АБД стикається з проблемою управління передачею

даних. Запити до БД від кінцевих користувачів повинні відбуватися під управлінням і

контролем спеціального програмного компонента – диспетчера. В загальному

випадку робоча станція користувача може бути фізично віддалена від самої БД на

значну відстань. Програма-диспетчер передачі даних не є частиною СУБД, а є окремим

додатком, що функціонує спільно і узгоджено.

        Однією з найпоширеніших сучасних є архітектура клієнт/сервер, яка надає

справжню свободу вибору і узгодження різних типів компонентів для клієнта, сервера і

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

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

Інформаційна система, побудована за принципом: клієнт/сервер, зазвичайно складається з таких трьох основних компонентів:

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

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

        Традиційно в клієнт/серверних системах використовуються дві ланки: клієнт і

сервер. При такій побудові основне програмне навантаження несе на собі клієнтська

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

        При розробці структури БД слід брати до уваги  такі фактори:

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

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

        В теорії БД таблиці називаються відношеннями, її стовпчики або поля – атрибутами, а рядки або записи – кортежами. Ці назви надають таблицям певного змісту, вони відрізняють таблиці БД від подібних інших, таких, наприклад, як таблиця MS Word. В межах цього посібника будемо користуватися термінами: таблиця, поле і запис, вкладаючи в них відповідний зміст. Ці терміни використовують практично всі СУБД.

        Таблиця БД має такі властивості:

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

        Таблиця може (як правило, БД містить декілька зв’язаних між собою таблиць, тому – мусить) мати один або декілька ключів. Ключ може бути простим або складеним. Простий ключ вживається найчастіше, це поле (його називають ключовим), значення якого однозначно ідентифікують кожний запис. Складений ключ складається з декількох імен полів. Існує декілька типів ключів. Серед інших первинний ключ (Primаry Key) має свої особливі властивості, а саме:

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

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

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

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

        Кожна таблиця містить мінімум одне поле, проте таблиця може не мати жодного запису. Без полів дані таблиці стають невизначеними, тоді як без записів у таблиці просто відсутні дані. У PostgreSQL 7.1 таблиця може містити до 1600 полів і необмежену кількість записів (точніше, обмежену тільки апаратними чинниками,наприклад, обсягом вільного дискового простору).

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

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

        У відповідності зі стандартом SQL92 незахищені ідентифікатори повинні перетворюватися до верхнього регістру, але PostgreSQL не забезпечує його вимоги даної частини стандарту SQL92. Ця обставина особливо важлива для адміністраторів баз даних, знайомих з іншими продуктами SQL, в яких ідентифікатори автоматично перетворюються до верхнього регістру (наприклад, Oracle).

        Ідентифікатори обов’язково повинні братися в лапки тільки у двох випадках: якщо ідентифікатор об’єкта бази даних збігається з ключовим словом або в його імені є хоча б одна велика літера.

       Максимальна довжина ключових слів і ідентифікаторів PostgreSQL дорівнює 31 символ. У процесі лексичного розбору всі ключові слова та ідентифікатори більшої довжини автоматично скорочуються. Ідентифікатори починаються з будь-якої букви англійського алфавіту (a ... z) або з символу підкреслення, далі йде довільне поєднання літер, цифр (0-9) і символів підкреслення. Ключові слова не можуть починатися або закінчуватися символом підкреслення, але для імен ідентифікаторів це дозволено. Ні ключові слова, ні ідентифікатори не можуть починатися з цифри, хоча в лапках таке імя стає прийнятним.

         Більше того, імена таблиць можуть містити деякі символи, які зазвичай вважаються неприпустимими (наприклад, пробіли або амперсанд, хоча наявність лапок, зрозуміло, заборонена). Хоча стандарт ANSI/ISO SQL не дозволяє створювати ідентифікатори з іменами, які збігаються з ключовими словами SQL, PostgreSQL (як і ряд інших реалізацій SQL) досить ліберально ставиться до цього обмеження – такі імена допустимі, але вони повинні братися в лапки. Проте, якщо потрібно, щоб команди SQL були стандартними і добре адаптувалися для інших платформ, слід дотримуватися стандартів ANSI/ISO.

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

        Розглянемо приклад побудови таблиць за правилами нормалізації. Нехай програміст користується зразками таких даних:

  1.  назва газопроводу;
  2.  кількість ниток газопроводу;
  3.  діаметр однієї нитки, м;
  4.  назва підприємства, яке експлуатує газопровід;
  5.  адреса підприємства (місто);
  6.  добова кількість транспортованого газу, м3;
  7.  дата обліку даних.

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

  1.  gazpr з полями:
  2.  kod_g (код газопроводу),
  3.  naz_g (назва газопроводу),
  4.  kil_n (кількість ниток),
  5.  diam (діаметр однієї нитки);
  6.  pidpr:
  7.  kod_p (код підприємства),
  8.  naz_p (назва підприємства),
  9.  misto (адреса підприємства);
  10.  oblik:
  11.  kod_g (код газопроводу),
  12.  kod_p (код підпримства),
  13.  kil_g (кількість транспортованого газу),
  14.  data (дата обліку даних).

       Правил є декілька, кожне наступне з них передбачає дотримання всіх попередніх, вони повинні забезпечувати:

  1.  (1 НФ – перша нормальна форма таблиці) атомарність значень полів. Не можна, наприклад, записати в одному й тому ж полі одного й того ж запису про газопровід поданої вище таблиці gazpr декілька назв підприємств, незважаючи на те, що вони його експлуатують;
  2.  (2 НФ) функціонально повну залежність всіх полів таблиці від первинного ключа. Це правило передбачає відсутність дублювання одних і тих же даних у різних таблицях. Наприклад, якщо назва та інші дані про газопроводи знаходяться в таблиці gazpr, то вони не повинні повторюватися в таблиці oblik про кількість щоденно транспортованого ним газу;
  3.  (3 НФ) відсутність транзитивних функціональних залежностей між полями таблиці, тобто всі поля таблиці повинні бути взаємно незалежними і повністю залежати від первинного ключа. У таблиці gazpr нашого прикладу всі дані про кожний газопровід не залежать одне від іншого, і стосуються лише конкретного коду газопроводу, який у даному випадку варто зробити первинним ключем;
  4.  (НФБК – нормальна форма Бойса-Кодда) можливість будь-якого поля, від якого функціонально залежить інше поле, бути ключем;
  5.  (4 НФ) відсутність багатозначних залежностей між полями таблиці;
  6.  (5 НФ) створення будь-якої залежності сполучення з проекцій (частин таблиці) за ключами, які в сукупності є можливим ключем таблиці. Таблиця задовільняє залежність сполучення, якщо вона відновлюється без втрат шляхом сполучення своїх проекцій. Це правило стосується таблиць, які мають складений ключ. Воно рідко застосовується в практичних умовах і має переважно теоретичне значення.

        З’єднання таблиць нашого прикладу між собою забезпечується за допомогою кодових полів, з яких код газопроводу таблиці gazpr і код підприємства таблиці pidpr можуть бути первинними ключами. Відповідні їм коди таблиці oblik – вторинні.

        Однак, аномалії в таблицях усунені не повністю. Якщо, наприклад, потрібно було б видати перелік газопроводів і відповідних їм підприємств, то для цього прийдеться використати таблицю oblik, де є відповідні їхні коди. Але, якщо якесь із підприємств ще не працювало, то й відомостей про нього не буде в цій таблиці, тому воно не ввійде у заданий перелік. Цю аномалію можна усунути, виготовивши ще одну 4-ту таблицю, яка міститиме два поля: коди газопроводів і коди відповідних їм підприємств.

        Можна назвати й інші можливі недоліки, які не стосуються правил нормалізації. Нехай, наприклад, підприємства володіють телефонами і їхні номери необхідно занести в таблицю pidpr. Тоді слід додати в неї ще одне поле з номерами телефонів. Але може статися, що різні підприємства мають різну кількість телефонів. Йдучи шляхом додавання в таблицю pidpr полів, кількість яких відповідатиме максимальному числу телефонів, одержимо велику кількість відсутності значень у тих записах, де вона менша за максимальну. Це може спричинити неефективне використанні пам’яті. В цій ситуації виникає задача оптимізації таблиць за певними критеріями, може виявитися, що вигідніше створити окрему таблицю з номерами телефонів і кодами їхніх власників, ніж додавати поля.

         Зв’язки між таблицями. Як уже було вище сказано, таблиці зв’язуються між собою за допомогою кодових полів, ключів. За кількістю зв’язки бувають:

  •  один до одного. Дві або більше таблиць, зв’язані за цим типом, практично є продовженням одна другої в ширину. Зрозуміло, що кількість записів таблиць, зв’язаних за цим типом, повинна бути однаковою. Можна обгрунтувати доцільність застосування цього типу зв’язку. По-перше, максимальна кількість полів таблиці, як правило, обмежена. Наприклад, СУБД MS Access дозволяє мати 256 полів у одній таблиці, PostgreSQL – 1600. Якщо кількість полів більша, то приходиться ділити таку таблицю на декілька, а при використанні даних з’єднувати їх між собою. По-друге, часто доцільно ділити й нешироку таблицю на декілька для зберігання секретної або конфіденційної інформації про об’єкт в окремій таблиці, тоді до неї можна обмежити доступ, залишивши таблицю з іншими даними про той же об’єкт загальнодоступною;
  •  один до багатьох або, що те ж саме, багато до одного. Прикладом такого зв’язку може бути назва кожного одного газопроводу таблиці gazpr до багатьох записів таблиці oblik про щоденну кількість транспортованого ним газу протягом часу обліку;
  •  багато до багатьох. Цей тип зв’язку не може бути безпосередньо реалізований у БД реляційного типу, він вимагає обов’язкової наявності проміжної таблиці. В нашому прикладі такою таблицею є oblik. За її допомогою можна зв’язати всі три наші таблиці, тобто багато газопроводів таблиці gazpr до багатьох підприємств таблиці pidpr через таблицю oblik. Якщо проміжної таблиці немає, то її слід спеціально створити.

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

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

     

        Запитання для самоперевірки

  1.  Що таке база даних, дані, система управління базами даних?
  2.  Перечисліть та коротко охарактеризуйте моделі даних.
  3.  Що таке таблиця, запис, поле, ключове поле, індекс.
  4.  Назвіть нормальні форми таблиць та коротко поясніть суть нормалізації. Чи може вважатися нормалізованою таблиця, якщо вона єдина в БД?
  5.  Перечисліть та поясніть типи зв’язків між таблицями.


 

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

21461. Лазерный пинцет 957 KB
  Сила с которой свет действует на окружающие объекты невелика но ее оказывается достаточно чтобы ловить и контролируемо перемещать частицы размером от 10 нм до 10 мкм. В дальнейшем Эшкин и его коллеги продемонстрировали возможности оптической ловушки на основе инфракрасного лазера захватывать удерживать и перемещать в пространстве различные биологические объекты такие как вирусные частицы одиночные бактериальные и дрожжевые клетки и органеллы в живых клетках водорослей. Как будет вести себя частица в поле после Пишейпера В случаях...
21462. Прецизионные волоконно-оптические датчики 333 KB
  100 Мрад Последовательного и параллельного типа Распределение температуры и деформации Обратное рассеяние Релея Интенсивность обратного рассеяния Релея Многомодовое Разрешающая способность 1 м Условия реализации волоконных датчиков связаны с наличием оптической комплектации: оптическое волокно в различных спектральных диапазонах. Соединительные и разделительные фильтры Многослойники дифракционные решетки; модуляторы интенсивности на основе электрооптического эффекта ниобат лития обладающий электрооптическими свойствами которые...
21463. Импульсный оптический рефлектометр 479 KB
  Введение Импульсные оптические рефлектометры OTDR Opticl Time Domin Reflectometer различных типов широко используются практически на всех этапах создания волоконнооптических систем связи: от производства волокна и оптического кабеля до строительства волоконнооптических линий связи ВОЛС и их эксплуатации. Измерять средние потери оптического волокна на катушках равномерность распределения потерь в волокне и выявлять наличие локальных дефектов при производстве волокна. Обнаруживать постепенное или внезапное ухудшение качества волокна...
21464. Анализ современного состояния техники ранней диагностики ВОЛП 706 KB
  Очевидно что длины волн используемые для передачи данных и для рефлектометрического контроля волокна в этом случае должны быть разными. В этой точке устанавливается оптический коммутатор OTU который по очереди включает волокна всех направлений в оптический путь сигналов рефлектометра RTU. Другой подход предполагает одновременное распространение сигнала рефлектометра по всем ответвляющимся волокнам. Согласно данным фирмы Fujikur по степени опасности для волокна можно выделить три диапазона значений его относительного удлинения.
21465. Двухчастотные лазерные интерферометры 1.42 MB
  Все оснащение лазерной измерительной головки заключающееся в системе программного и инструментального обеспечения измерения предназначено для линейных и угловые измерений измерения плоскостности измерения прямолинейности измерения взаимоперпендикулярности и измерения скорости перемещения. Дискрет измерения равен  при статистической обработке сигнала fd его можно уменьшить в 10 раз. Таким образом дискретность измерения интерферометра не превышает 001 мкм. Чтобы исключить ошибку связанную с температурным расширением основания на...
21466. Частота и частотные характеристики лазерного излучения 168.5 KB
  Для одной моды в том случае когда реализуется одномодовый режим можно ввести такой параметр как ширина линии излучения . Время когерентности и длина когерентности вводятся также и для многочастотного излучения. Особенность свойств когерентности излучения фемтосекундного лазера.
21467. Стандарты частоты газовые 1.6 MB
  Лазеры точнее лазерное излучение позволили создать такие источники оптического излучения с такими узкими линиями излучения которые в принципе не могли существовать в естественных условиях. С развитием лазеров появилась возможность не только управлять но и стабилизировать частоту оптического излучения. В результате этого решения появилась возможность на базе лазеров у которых частота излучения и длина волны излучения в вакууме связаны простым соотношением создавать стандарты частоты и длины волны.
21468. Одночастотный лазерный интерферометр Майкельсона. Принципы измерения расстояний и линейных перемещений 395.5 KB
  1 Упрощенная схема интерферометра Майкельсона При рассмотрении двухлучевых интерферометров следует обратить внимание на временные и пространственные фазы излучения. Поскольку основным уравнением интерферометрии является уравнение для интенсивности излучения сформированного двумя полями 1 2...
21469. Лазерный доплеровский анемометр 610.5 KB
  Движущиеся вместе с газовым потоком частицы рассматриваются как приемники световых волн от неподвижного источника и одновременно как передатчикиретрансляторы оптического излучения к неподвижному наблюдателю. Частота рассеянного излучения в точке наблюдения равна: 1 где ν – частота излучения источника; с – скорость света; u – проекция скорости частицы в направлении на точку наблюдения. Итак Доплеровская частота сигнала на выходе фотоприемника зависит от длины волны лазерного излучения скорости частиц и геометрии оптической системы....