Оптимизација на прашалници и погледи

Optimizacija i Prashalnici

Оптимизација на прашалници и погледи

---

View 1: Најава на корисник (Login view)

• Филтри: Примарен филтер за погледот v_user_login ќе биде според username, а дополнително се филтрира само на корисници со статус ACTIVE.

• Употреба: е процесот на логирање на клиент во системот. Погледот обезбедува брз пристап до корисничкото име, и статусот на сметката.

• Иницијално време: Иницијалното време за извршување на погледот е 0.315ms. Ова е прифатливо време за апликацијата.

• Најбавните операции се две Index Scan операции:
  • Index Scan на табела client_user преку индексот client_user_username_key - Actual Total Time: 0.039ms
  • Index Scan на табела client преку индексот client_pkey - Actual Total Time: 0.013ms

• Вкупниот Nested Loop завршува за само 0.056ms. Бидејќи се работи за Index Scan (не Full Scan), операциите не можат значително да се подобрат со дополнителни индекси.

• Времето изминато во извршување на операциите insert и update изнесува

• Нема потреба да се преуреди прашалникот.

• Време на извршување на операциите insert и update останува исто.

---

View 2: Извештаи (Receipt view)

• Филтри: Примарен филтер за погледот v_client_receipts ќе биде според client_id, а дополнително може да се користи и според transaction_date (по временски период - месец и година).

• Употреба: Примарен случај на употреба е преглед на издадени сметки за клиент по одреден период. За овој поглед ни се важни перформансите, бидејќи без него се губи време при извршување.

• Иницијално време: Иницијалното време за извршување на погледот e 705ms. Ова е прифатливо време за апликацијата.

• Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е

• Нема потреба да се преуреди прашалникот.

• Време на извршување на операциите insert и update останува исто.

---

View 3: Рати (Loan installments view)

• Филтри: Примарен филтер за погледот v_loan_installments ќе биде според loan_id.

• Употреба: Примарен случај на употреба е кога клиентот или банкарскиот персонал сака да ги прегледа ратите за конкретен кредит. За овој поглед ни се важни перформансите.

• Иницијално време: Иницијалното време за извршување на погледот е 250.5ms. Ова е прифатливо време за апликацијата.

• Нема потреба од правење план на извршување, бидејќи времето е задоволително. Пребарувањето по loan_id секогаш враќа мал број рати за конкретен кредит, па табелата не се пребарува со висока фреквенција истовремено. Времето на операциите insert и update изнесува

• Нема потреба да се преуреди прашалникот.

• Времето на извршување на операциите insert и update останува исто.

---

View 4: Преглед на кредити

• Филтри: Примарен филтер за погледот v_loan_details ќе биде според loan_id, а исто така и според client_id.

• Употреба: Примарен случај на употреба е целосен преглед на кредитна апликација. За овој поглед ни се важни перформансите, бидејќи без него се губи многу време при извршување.

• Иницијално време: Иницијалното време за извршување на погледот e 1s 735ms. Времето е побавно поради повеќе JOIN операции и full scan на табелите Account и Collateral. Ова не е прифатливо за апликацијата.

• Најбавните операции се JOIN-овите на Account и Collateral преку loan_id, кои немаат индекси на надворешниот клуч.

• Времето изминато во извршување на операциите insert и update изнесува

• Времето изминато во извршување на query-то со индекси изнесува 781ms, и тоа е прифатливо време.

• Времето изминато во извршување на операцијата update по индексирање изнесува

---

View 5: Трансфери меѓу сметки, трансакции

• Филтри: Примарен филтер за погледот v_client_transfers ќе биде според sender_client_id, а дополнително и според transaction_date.

• Употреба: Примарен случај на употреба е кога клиентот сака да ги прегледа своите извршени трансфери. За овој поглед ни се важни перформансите.

• Иницијално време: Иницијалното време за извршување на погледот е 68ms. Времето е прифатливо, бидејќи JOIN операциите се базираат на примарни и надворешни клучеви кои веќе имаат индекси.

• Најбавните операции не претставуваат значителен проблем. Двојниот JOIN на Account и Client (за испраќач и примач) се изведува ефикасно преку постојните индекси.

• Времето на операциите insert и update изнесува

• Нема потреба да се преуредува прашалникот.

• Времето на извршување на операциите insert и update останува исто.

---

View 6: Сомнителни трансакции

• Филтри: Примарен филтер за погледот v_suspicious_transactions е amount > 9000 AND status IN ('PENDING', 'FAILED').

• Употреба: Примарен случај на употреба е мониторинг на потенцијално сомнителна активност (AML). За овој поглед ни се важни перформансите, бидејќи без него се губи многу време при извршување.

• Иницијално време: Иницијалното време за извршување на погледот е 8s 15ms. Времето за извршување е побавно поради full scan на табелата Transaction за да се пронајдат записите со висок износ. Ова не е прифатливо за апликацијата, па затоа пристапуваме кон индексирање.

• Најбавните операции се full scan на Transaction за филтрирање по amount и status, и JOIN со Account без индекс на client_id.

• Времето изминато во извршување на insert и update изнесува

• Времето изминато во извршување на query-то со индекси изнесува 669ms, и тоа е прифатливо време.

• Времето изминато во извршување на операцијата update по индексирање изнесува

---

View 7: Вкупна состојба на клиент

• Филтри: Примарен филтер за погледот v_account_balance ќе биде според client_id.

• Употреба: Примарен случај на употреба е кога клиентот сака да го провери балансот на своите сметки. Овде се битни перформансите, затоа што сакаме апликацијата да функционира без застој.

• Иницијално време: Иницијалното време за извршување на овој поглед изнесува 88ms. Времето е мало и прифатливо, бидејќи JOIN-овите се на примарни клучеви.

• Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операции insert и update изнесува

• Нема потреба да се преуреди прашалникот.

• Време на извршување на операциите insert и update останува исто.

---

View 8: Следење на доцнења (Loan Default Monitoring)

• Филтри: Примарен филтер за погледот v_loan_default_monitoring ќе биде според installment_status IN ('PENDING','LATE') и due_date, со услов paid_date IS NULL.

• Употреба: Примарен случај на употреба е кога банкарскиот персонал сака да ги идентификува клиентите кои задоцниле со плаќање. За овој поглед ни се важни перформансите, бидејќи без него се губи многу време при извршување.

• Иницијално време: Иницијалното време за извршување на погледот е 9s 289ms. Иницијалното време за извршување на погледот беше побавно поради full scan на табелата Loan_installment. Ова не е прифатливо време за апликацијата па затоа пристапуваме кон индексирање.

• Најбавните операции се full scan на Loan_installment без филтрирање на платените рати, и JOIN со Account без covering индекс.

• Времето изминато во извршување на INSERT и UPDATE пред изнесува

• Времето изминато во извршување на query-то со индекси изнесува 597.9ms, и тоа е прифатливо време.

• Времето изминато во извршување на операциите insert и update по индексирање изнесува

---

View 9: Accounts (сметки)

• Филтри: Примарен филтер за погледот v_accounts ќе биде според client_id.

• Употреба: Примарен случај на употреба е преглед на сите сметки на клиент при услуги на шалтер. Овде се битни перформансите.

• Иницијално време: Иницијалното време за извршување на овој поглед е 100ms, што е прифатливо, па затоа нема да имаме потреба од индексирање.

• Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е

• Нема потреба да се преуредува прашалникот.

• Времето на извршување на операциите insert и update останува исто.

---

View 10: Камати по штедни сметки

• Филтри: Примарен филтер за погледот v_savings_interest_payments ќе биде според client_id.

• Употреба: Примарен случај на употреба е кога клиентот сака да ги прегледа добиените камати по период. Овде се важни перформансите.

• Иницијално време: Иницијалното време за извршување на овој поглед е 214ms, што е прифатливо, па затоа нема да имаме потреба од индексирање.

• Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е

• Нема потреба да се преуредува прашалникот.

• Времето на извршување на операциите insert и update останува исто.

---

View 11: Дневен извештај на филијала

• Филтри: Примарен филтер за погледот v_daily_branch_report ќе биде според branch_id, а дополнително и според report_date.

• Употреба: Примарен случај на употреба е кога раководството на филијалата или централниот менаџмент сака да ги следи дневните активности. Овде се битни перформансите.

• Иницијално време: Иницијалното време за извршување на погледот е 385ms. Ова е прифатливо време за апликацијата.

• Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е

• Нема потреба да се преуредува прашалникот.

• Времето на извршување на операциите insert и update останува исто.

---

Членови на тим:

Михаела Ковчегарска 231068
Јована Мечева 231124
Емилија Костова 231107