== Оптимизација на прашалници и погледи == === View 1: Најава на корисник (Login view) === 1. '''Филтри:''' Примарен филтер за погледот `v_user_login` ќе биде според `username`, а дополнително се филтрира само на корисници со статус `ACTIVE`. 2. '''Употреба:''' е процесот на логирање на клиент во системот. Погледот обезбедува брз пристап до корисничкото име, и статусот на сметката. 3. '''Иницијално време:''' Иницијалното време за извршување на погледот е 0.315ms. Ова е прифатливо време за апликацијата. [[Image(v_user_login_et.JPG, width=890)]] 4. Најбавните операции се две 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), операциите не можат значително да се подобрат со дополнителни индекси. [[Image(v_user_login_fullsc_paint.jpg, width=890)]] * Времето изминато во извршување на операциите insert и update изнесува [[Image(insert_.JPG, width=890)]] [[Image(update_.JPG, width=890)]] 5. Нема потреба да се преуреди прашалникот. 6. Време на извршување на операциите insert и update останува исто. === View 2: Извештаи (Receipt view) === 1. '''Филтри:''' Примарен филтер за погледот `v_client_receipts` ќе биде според `client_id`, а дополнително може да се користи и според `transaction_date` (по временски период - месец и година). 2. '''Употреба:''' Примарен случај на употреба е преглед на издадени сметки за клиент по одреден период. За овој поглед ни се важни перформансите, бидејќи без него се губи време при извршување. 3. '''Иницијално време:''' Иницијалното време за извршување на погледот e 705ms. Ова е прифатливо време за апликацијата. [[Image(client_receipts.JPG, width=890)]] 4. Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е [[Image(insert_transaction.JPG, width=890)]] [[Image(insert_receipt.JPG, width=890)]] [[Image(update_transaction.JPG, width=890)]] 5. Нема потреба да се преуреди прашалникот. 6. Време на извршување на операциите insert и update останува исто. === View 3: Рати (Loan installments view) === 1. '''Филтри:''' Примарен филтер за погледот `v_loan_installments` ќе биде според `loan_id`. 2. '''Употреба:''' Примарен случај на употреба е кога клиентот или банкарскиот персонал сака да ги прегледа ратите за конкретен кредит. За овој поглед ни се важни перформансите. 3. '''Иницијално време:''' Иницијалното време за извршување на погледот е 250.5ms. Ова е прифатливо време за апликацијата. [[Image(v_loan_installment_et.JPG, width=890)]] 4. Нема потреба од правење план на извршување, бидејќи времето е задоволително. Пребарувањето по `loan_id` секогаш враќа мал број рати за конкретен кредит, па табелата не се пребарува со висока фреквенција истовремено. Времето на операциите insert и update изнесува [[Image(insert.JPG,width=890)]] [[Image(update.JPG, width=890)]] 5. Нема потреба да се преуреди прашалникот. 6. Времето на извршување на операциите insert и update останува исто. === View 4: Преглед на кредити === 1. '''Филтри:''' Примарен филтер за погледот `v_loan_details` ќе биде според `loan_id`, а исто така и според `client_id`. 2. '''Употреба:''' Примарен случај на употреба е целосен преглед на кредитна апликација. За овој поглед ни се важни перформансите, бидејќи без него се губи многу време при извршување. 3. '''Иницијално време:''' Иницијалното време за извршување на погледот e 1s 735ms. Времето е побавно поради повеќе JOIN операции и full scan на табелите Account и Collateral. Ова не е прифатливо за апликацијата. 4. Најбавните операции се JOIN-овите на Account и Collateral преку `loan_id`, кои немаат индекси на надворешниот клуч. * Времето изминато во извршување на операциите insert и update изнесува 5. Времето изминато во извршување на query-то со индекси изнесува 781ms, и тоа е прифатливо време. 6. Времето изминато во извршување на операцијата update по индексирање изнесува === View 5: Трансфери меѓу сметки, трансакции === 1. '''Филтри:''' Примарен филтер за погледот `v_client_transfers` ќе биде според `sender_client_id`, а дополнително и според `transaction_date`. 2. '''Употреба:''' Примарен случај на употреба е кога клиентот сака да ги прегледа своите извршени трансфери. За овој поглед ни се важни перформансите. 3. '''Иницијално време:''' Иницијалното време за извршување на погледот е 68ms. Времето е прифатливо, бидејќи JOIN операциите се базираат на примарни и надворешни клучеви кои веќе имаат индекси. 4. Најбавните операции не претставуваат значителен проблем. Двојниот JOIN на Account и Client (за испраќач и примач) се изведува ефикасно преку постојните индекси. * Времето на операциите insert и update изнесува 5. Нема потреба да се преуредува прашалникот. 6. Времето на извршување на операциите insert и update останува исто. === View 6: Сомнителни трансакции === 1. '''Филтри:''' Примарен филтер за погледот `v_suspicious_transactions` е `amount > 9000 AND status IN ('PENDING', 'FAILED')`. 2. '''Употреба:''' Примарен случај на употреба е мониторинг на потенцијално сомнителна активност (AML). За овој поглед ни се важни перформансите, бидејќи без него се губи многу време при извршување. 3. '''Иницијално време:''' Иницијалното време за извршување на погледот е 8s 15ms. Времето за извршување е побавно поради full scan на табелата Transaction за да се пронајдат записите со висок износ. Ова не е прифатливо за апликацијата, па затоа пристапуваме кон индексирање. 4. Најбавните операции се full scan на Transaction за филтрирање по `amount` и `status`, и JOIN со Account без индекс на `client_id`. * Времето изминато во извршување на insert и update изнесува 5. Времето изминато во извршување на query-то со индекси изнесува 669ms, и тоа е прифатливо време. 6. Времето изминато во извршување на операцијата update по индексирање изнесува === View 7: Вкупна состојба на клиент === 1. '''Филтри:''' Примарен филтер за погледот `v_account_balance` ќе биде според `client_id`. 2. '''Употреба:''' Примарен случај на употреба е кога клиентот сака да го провери балансот на своите сметки. Овде се битни перформансите, затоа што сакаме апликацијата да функционира без застој. 3. '''Иницијално време:''' Иницијалното време за извршување на овој поглед изнесува 88ms. Времето е мало и прифатливо, бидејќи JOIN-овите се на примарни клучеви. 4. Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операции insert и update изнесува 5. Нема потреба да се преуреди прашалникот. 6. Време на извршување на операциите insert и update останува исто. === View 8: Следење на доцнења (Loan Default Monitoring) === 1. '''Филтри:''' Примарен филтер за погледот `v_loan_default_monitoring` ќе биде според `installment_status IN ('PENDING','LATE')` и `due_date`, со услов `paid_date IS NULL`. 2. '''Употреба:''' Примарен случај на употреба е кога банкарскиот персонал сака да ги идентификува клиентите кои задоцниле со плаќање. За овој поглед ни се важни перформансите, бидејќи без него се губи многу време при извршување. 3. '''Иницијално време:''' Иницијалното време за извршување на погледот е 9s 289ms. Иницијалното време за извршување на погледот беше побавно поради full scan на табелата Loan_installment. Ова не е прифатливо време за апликацијата па затоа пристапуваме кон индексирање. 4. Најбавните операции се full scan на `Loan_installment` без филтрирање на платените рати, и JOIN со Account без covering индекс. * Времето изминато во извршување на INSERT и UPDATE пред изнесува 5. Времето изминато во извршување на query-то со индекси изнесува 597.9ms, и тоа е прифатливо време. 6. Времето изминато во извршување на операциите insert и update по индексирање изнесува === View 9: Accounts (сметки) === 1. '''Филтри:''' Примарен филтер за погледот `v_accounts` ќе биде според `client_id`. 2. '''Употреба:''' Примарен случај на употреба е преглед на сите сметки на клиент при услуги на шалтер. Овде се битни перформансите. 3. '''Иницијално време:''' Иницијалното време за извршување на овој поглед е 100ms, што е прифатливо, па затоа нема да имаме потреба од индексирање. 4. Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е 5. Нема потреба да се преуредува прашалникот. 6. Времето на извршување на операциите insert и update останува исто. === View 10: Камати по штедни сметки === 1. '''Филтри:''' Примарен филтер за погледот `v_savings_interest_payments` ќе биде според `client_id`. 2. '''Употреба:''' Примарен случај на употреба е кога клиентот сака да ги прегледа добиените камати по период. Овде се важни перформансите. 3. '''Иницијално време:''' Иницијалното време за извршување на овој поглед е 214ms, што е прифатливо, па затоа нема да имаме потреба од индексирање. 4. Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е 5. Нема потреба да се преуредува прашалникот. 6. Времето на извршување на операциите insert и update останува исто. === View 11: Дневен извештај на филијала === 1. '''Филтри:''' Примарен филтер за погледот `v_daily_branch_report` ќе биде според `branch_id`, а дополнително и според `report_date`. 2. '''Употреба:''' Примарен случај на употреба е кога раководството на филијалата или централниот менаџмент сака да ги следи дневните активности. Овде се битни перформансите. 3. '''Иницијално време:''' Иницијалното време за извршување на погледот е 385ms. Ова е прифатливо време за апликацијата. 4. Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е 5. Нема потреба да се преуредува прашалникот. 6. Времето на извршување на операциите insert и update останува исто. '''Членови на тим:''' Михаела Ковчегарска 231068[[BR]] Јована Мечева 231124[[BR]] Емилија Костова 231107