💸 Как сделать бизнес проще, а карман толще?

Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже. Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал. Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!

Технологія проектування ІС на мережах ЕОМ

Tехнологічною базою мережевих ІС є локальні обчислювальні мережі, а також компоненти глобальних комп'ютерних мереж.

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

Виникнення і використання ЛОМ в ІС визначається трьома чинниками:

- розподілом ресурсів (процесорів, пам'яті, пристроїв, друку та ін.);

- введення і зберігання даних у місці їх виникнення;

- доступ до віддалених даних.

Основне навантаження у мережі зосереджується, як правило, на комп'ютерах, що виділяють у мережу свої ресурси.

Існує три основних підходи до організації обробки даних у комп`ютерній мережі;

- обробка даних за методом «клієнт — сервер»;

- розподілена система обробки даних;

- розподілена база даних.

Поряд з проблемами, що виникають при розробці ІС на окремих машинах, мережеві ІС породжують додатково своє коло проблем. Розглянемо деякі з них:

1. У користувача мережевої ІС має зберігатися ілюзія роботи з великою централізованою базою даних. Це породжує необхідність у використанні деякого загального уявлення про дані — глобальну кон­цептуальну схему.

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

3. Дублювання даних (як один з аспектів секціонування) має бути прозорим. Це породжує ряд супровідних проблем:

а) забезпечення синхронізації відновлення копій;

б) якщо для коригувань використовувати метод блокувань, то час коригування може дуже подовжитися.

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

а) глобальний словник сам є деякою розподіленою базою даних;

б) секціонування і розподіл словника вимагатиме створення мета-словника, який описує розміщення словника.

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

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

Етап 1. Скласти модель «процес — ділянка», яка б відображувала ему розміщення кожного процесу за ділянками організації.

Етап 2. Побудувати модель «ділянки — предметні бази даних», яка і відображувала схему використання ділянками різних предметних БД (супергруп об'єктів).

Етап 3. На основі моделей «процес — ділянка» і «ділянки — предметні БД» (етапи 1 і 2) побудувати модель “процеси/ділянки — предметні БД”, яка б відображувала ділянки користувачів і процеси на предметні бази даних.

Етап 4. Визначити (орієнтовно, експертним шляхом, за даними функціонування попередніх періодів) обсяг транзакцій між ділянками розміщення процесів і даними. Оцінити, чи транзакції переважно діалогові, чи пакетні.

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

Етап 6. Будується структурна модель «процеси/ділянки — ділян-ки/предметні БД» із зазначенням обсягів транзакції. Ця модель доповнює модель із зазначенням розташування даних за ділянками і типами їх розподілу. Модель подасться у вигляді таблиці.

Етап 7. Побудувати матрицю структури даних у прив'язці баз даних до вузлів мережі ЕОМ.

Етап 8. Дослідити, як впливають чинники, визначені раніше на якість розподіленої структури даних, одержаної на етапі 7. Розглядати проблеми оновлення, надійності та рестарту. За необхідністю скоригувати матрицю етапу 7.

Етап 9. Визначити, які транзакції використовуються для реалізації процесів і які для них необхідні прикладні програми (прикладні задачі). Побудувати матрицю «прикладні програми — предметні БД/ділянки».

Етап 10. Віднести кожну з прикладних програм до одного з класів. Скласти таблицю числа програм кожного ласу. Перебудувати матрицю структури даних (етап 7) так, щоб число програм класу 1 було максимальним; програми класу 3 були відсутні; програм класу 2 було якомога менше.

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

Існує змога вибору однієї з двох технологій:

- орієнтованої на локальну мережу;

- СУБД типу «клієнт — сервер».

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

База даних, орієнтована на локальну мережу, працює тільки на робочих станціях клієнтів. Ці станції управляють блокуванням багатокористувальних файлів і записів інформації, яка зберігається на файл-сервері. До цієї категорії належать: усі клони системи dBase, Advance Revelation, Rbase, Рагаdox та інші.

Основні аргументи при виборі СУБД, орієнтованої на локальну ме­режу:

- з допомогою продуктів такого типу можна швидко розробляти порівняно прості бази даних;

- залежно від виду прикладних задач можна змінювати фізичну організацію інформації у базі даних.

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

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

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

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

У моделі «клієнт — сервер» ці два процеси розділені так, що інтерфейс користувача реалізується на робочій станції, а механізм ба­зи даних — на окремому мережевому сервері СУБД.

Прикладом СУБД типу «клієнт — сервер» Огасl, Sуbаsе, ХQL фірми Novell.

У великій мережі СУБД типу «клієнт — сервер» має забезпечувати виконання великої кількості транзакцій у секунду порівняно із систе­мою, орієнтованою на локальну мережу.

Недоліки архітектури «клієнт — сервер»:

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

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

- вимагається дуже висока кваліфікація персоналу.

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

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

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

Традиційна помилка - використання великої кількості блокувань протягом надто тривалого часу.

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

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

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

При пошуку необхідного поєднання компонентів локальної мережі і СУБД - розробки необхідно враховувати такі особливості:

- розуміти відмінності в СУБД, що орієнтовані на локальну мережу, і СУБД типу «клієнт — сервер», а також усвідомлювати обмежені можливості СУБД, орієнтованої на локальну мережу, зокрема при об­слуговуванні великої кількості кінцевих користувачів;

- використовувати нормалізацію БД при розробці її логічної оптимізованої моделі, базуючись на потребах користувача;

- узгоджувати рівень паралелізму інформації з потребами кінцевого користувача;

- обмежувати рівень блокування файлів і записів;

- підтримувати файли у закритому стані якомога далі;

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

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

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

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