១. សេចក្កីផ្ដើម 

១.១. ផ្ទៃក្នុង និងកម្លាំងជំរុញ(Background and Motivation)

នៅក្នុងប្រទេសកំពុងអភិវឌ្ឍន៍ភាគច្រើនដូចជាប្រទេសឥណ្ឌា កសិកម្មត្រូវបានចាត់ទុកថាជាប្រភពចំណូលដ៏សំខាន់។ កសិករប្រមូលផលដំណាំផ្សេងៗគ្នាអាស្រ័យលើកត្តាបរិស្ថាន និងតម្រូវការស្បៀង។ ប៉ុន្តែកសិករប្រឈមមុខនឹងបញ្ហាមួយចំនួនដោយសារលក្ខខណ្ឌបរិស្ថាន និងជំងឺដែលកើតឡើងលើដំណាំ[2]។ ចំពោះដំណាំផ្កាឈូករ័ត្នត្រូវបានដាំដុះជាទូទៅសម្រាប់ប្រមូលគ្រាប់ពូជ ការផលិតជាប្រេង និងការប្រើប្រាស់សម្រាប់លម្អ។ ទោះជាយ៉ាងណាក៏ដោយ រុក្ខជាតិផ្កាឈូករ័ត្នគឺងាយរងគ្រោះទៅនឹងជំងឺមួយចំនួន សត្វល្អិត និងបញ្ហាសារធាតុចិញ្ចឹម។ បញ្ហាទាំងនេះអាចប៉ះពាល់ដល់ការលូតលាស់ កាត់បន្ថយទិន្នផល និងអាចសម្លាប់រុក្ខជាតិបាន ប្រសិនបើមិនបានកំណត់អត្តសញ្ញាណទាន់ពេលវេលា។ 

ប្រព័ន្ធអ្នកជំនាញអាចដើរតួរជាជំនួយការឌីជីថល ដោយផ្តល់នូវការណែនាំដំបូងៗដោយផ្អែកលើសំណុំចំណេះដឹងដែលមានរចនាសម្ពាន្ធត្រឹមត្រូវ។ ការប្រើប្រាស់បច្ចេកវិទ្យាដូចជា Flask និង SQL Alchemy អាចធានបាននូវការអនុវត្តន៍ដែលអាចចូលដំណើរការបាន និងងាយស្រួលប្រើប្រាស់។ ការអភិវឌ្ឍន៍ប្រព័ន្ធបែបនេះ អាចជួយសម្រួលបន្ទុកដល់កសិករក្នុងការដោះស្រាយបញ្ហាដំណាំផ្កាឈូករ័ត្ន ។

១.២. សេចក្តីថ្លែងការណ៍អំពីបញ្ហា(Problem Statement)

មនុស្សជាច្រើនខ្វះចំណេះដឹងដើម្បីកំណត់ជំងឺផ្កាឈូករ័ត្នឱ្យបានត្រឹមត្រូវ។ ការធ្វើរោគវិនិច្ឆ័យភាគច្រើនពឹងផ្អែកលើបទពិសោធន៍ដែលពួកគាត់មាន ជាពិសេសអ្នកដែលចាប់ផ្តើមដាំដុះផ្កាឈូករ័ត្នជាលើកដំបូង។ ដោយគ្មានការណែនាំត្រឹមត្រូវ

រុក្ខជាតិផ្កាឈូករ័ត្នអាចទទួលរងពីការធ្វើរោគវិនិច្ឆ័យខុស និងការព្យាបាលមិនត្រឹមត្រូវ។ ដូច្នេះហើយ វាតម្រូវឲ្យមានតម្រូវការសម្រាប់ប្រព័ន្ធសាមញ្ញដែលអាចជួយអ្នកប្រើប្រាស់កំណត់អត្តសញ្ញាណជំងឺដែលអាចកើតមានដោយផ្អែកលើរោគសញ្ញាដែលអាចមើលឃើញ។

១.៣. គោលបំណងនៃការស្រាវជ្រាវ(Research Objectives)

គោលដៅចម្បងនៃការស្រាវជ្រាវនេះគឺដើម្បីដោះស្រាយបញ្ហាដែលបានលើកឡើង ដោយផ្ដោតលើគោលបំណងចម្បងដូចខាងក្រោម៖

·       អភិវឌ្ឍន៍ : អភិវឌ្ឍន៍ប្រព័ន្ធអ្នកជំនាញដោយផ្អែកលើច្បាប់ដោយប្រើ Flask និង SQL Alchemy ដើម្បីធ្វើរោគវិនិច្ឆ័យរោគសញ្ញាដំណាំផ្កាឈូករ័ត្ន។

·       រចនា : រចនាមូលដ្ឋានចំណេះដឹងអនុសាសន៍ដែលអាចពង្រីកបាន ដែលមានសម្ថភាពផ្ទុកច្បាប់វិនិច្ឆ័យរោគដែលមានភាពស្មុកស្មាញ។

១.៤. រចនាសម្ព័ន្ធឯកសារ(Paper Structure)

ឯកសារនេះត្រូវបានរៀបចំជាផ្នែកសំខាន់ៗជាច្រើន។ ផ្នែកទី១ ផ្ដល់នូវសេចក្ដីផ្ដើម ផ្ទៃក្នុង កម្លាំងជំរុញ និងគោលបំណងនៃការស្រាវជ្រាវ។ ផ្នែកទី ២ ពិនិត្យឡើងវិញនូវការងារដែលពាក់ព័ន្ធ និងផ្ដល់់នូវការវិភាគប្រៀបធៀបនៃប្រព័ន្ធជំនាញដែលមានស្រាប់។ ផ្នែកទី ៣ រៀបរាប់លម្អិតអំពីវិធីសាស្រ្តស្រាវជ្រាវ រួមទាំងស្ថាបត្យកម្មប្រព័ន្ធ និងការបង្កើតម៉ូដែលចំណេះដឹង។ ផ្នែកទី ៤ បង្ហាញពីការអនុវត្ត និងលទ្ធផលនៃការវាយតម្លៃពិសោធន៍របស់ប្រព័ន្ធ។ ចុងក្រោយ ផ្នែកទី ៥ សង្ខេបសេចក្កីសន្និដ្ឋាននៃការសិក្សា និងគូសបញ្ជាក់ការកែលម្អនាពេលអនាគត។

២. ការងារដែលពាក់ព័ន្ធ / ការពិនិត្យអក្សរសិល្ប៍ (RELATED WORK / LITERATURE REVIEW)

២.១ ប្រព័ន្ធជំនាញក្នុងការវិនិច្ឆ័យកសិកម្ម (Expert Systems in Agricultural Diagnosis)

្រព័ន្ធអ្នកជំនាញ ES ត្រូវបានសិក្សាជាផ្នែកមួយនៃ AI នៅក្នុងវិស័យកសិកម្មចាប់តាំងពីចុងទសវត្សរ៍ឆ្នាំ 1970 និងដើមទស្សវត្សរ៍ឆ្នាំ 1980 ដោយមានគោលបំណងធ្វើត្រាប់តាមអ្នកជំនាញនៅក្នុងដែនជាក់លាក់[3]។ នៅក្នុងការធ្វើរោគវិនិច្ឆ័យកសិកម្ម ប្រព័ន្ធអ្នកជំនាញត្រូវបានប្រើដើម្បីកំណត់ជំងឺដំណាំដោយផ្អែកលើរោគសញ្ញាដែលអាចសង្កេតបានដែលផ្តល់ដោយអ្នកប្រើប្រាស់។ ប្រព័ន្ធទាំងនេះរក្សាទុកចំណេះដឹងកសិកម្មអ្នកជំនាញ រួមទាំងលក្ខណៈជំងឺ និងរោគសញ្ញានៅក្នុងមូលដ្ឋានចំណេះដឹង និងអនុវត្តហេតុផលឡូជីខលដើម្បីបង្កើតការសន្និដ្ឋានរោគវិនិច្ឆ័យ។ វិធីសាស្រ្តនេះមានប្រយោជន៍ជាពិសេសនៅក្នុងតំបន់ដែលលទ្ធភាពទទួលបានអ្នកជំនាញកសិកម្មមានកម្រិត[3]។

ការស្រាវជ្រាវថ្មីៗ (2019-2026) បង្ហាញថាប្រព័ន្ធអ្នកជំនាញកសិកម្មជាច្រើនបានទទួលយកហេតុផលផ្អែកលើច្បាប់ ដើម្បីយកគំរូតាមការសម្រេចចិត្តរបស់អ្នកជំនាញ។ ប្រសិទ្ធភាពនៃប្រព័ន្ធទាំងនេះភាគច្រើនអាស្រ័យទៅលើការទទួលបានចំណេះដឹងត្រឹមត្រូវ និងសមត្ថភាពក្នុងការដោះស្រាយភាពមិនច្បាស់លាស់ ដោយសាររោគសញ្ញាជំងឺរុក្ខជាតិអាចប្រែប្រួលដោយសារកត្តាបរិស្ថាន[3]។

ទោះបីជាប្រព័ន្ធអ្នកជំនាញកសិកម្មដែលមានស្រាប់បានបង្ហាញពីលទ្ធផលដ៏ជោគជ័យក៏ដោយ ភាគច្រើនត្រូវបានរចនាឡើងសម្រាប់ដំណាំជាក់លាក់ និងខ្វះភាពបត់បែនសម្រាប់ការធ្វើរោគវិនិច្ឆ័យជំងឺកាន់តែទូលំទូលាយ។ ដែនកំណត់ទាំងនេះបង្ហាញពីតម្រូវការសម្រាប់ប្រព័ន្ធអ្នកជំនាញដែលមានរចនាសម្ព័ន្ធល្អ ដែលអាចគាំទ្រការធ្វើរោគវិនិច្ឆ័យត្រឹមត្រូវ និងអាចសម្របខ្លួនបាន ដូចជាប្រព័ន្ធដែលត្រូវបានបង្កើតឡើងសម្រាប់ការកំណត់អត្តសញ្ញាណជំងឺផ្កាឈូករ័ត្នជាដើម។

២.២ ប្រព័ន្ធកសិកម្មផ្អែកលើច្បាប់ (Rule-Based Agricultural Systems)

ប្រព័ន្ធបែបកសិកម្មដែលផ្អែកលើ IF_THEN Rules ដើម្បីភ្ជាប់រោគសញ្ញា (Antecedent) ជាមួយនឹងការវិនិច្ឆ័យ (Consequent)។ ដំណើរការវិស្វកម្មចំណេះដឹង (Knowledge Engineering) នៅក្នុងប្រព័ន្ធនេះទាមទារឲ្យមានការសិក្សាស្រាវជ្រាវឲ្យបានស៊ីជម្រៅទាក់ទងនឹងRule-Based Knowledge នៃផ្កាឈូករ័ត្ន ដើម្បីទទួលបានភាពត្រឹមត្រូវ និងស៊ីសង្វាក់គ្នា។

ដែនកំណត់ដ៏សំខាន់នៃប្រព័ន្ធច្បាប់ឋិតិវន្ត(Static Rule Bases)​គឺភាពលំបាកក្នុងការកែប្រែនៅពេលមានព័ត៌មានរោគសញ្ញាថ្មីៗកើតឡើង ដែលប្រព័ន្ធជារឿយៗខ្វះយន្តការដែលអាចរៀនដោយស្វ័យប្រវត្តិពីអ្វីថ្មីៗទាំងនោះ។ ដូច្នេះការងារនេះបានផ្តោតលើការរចនាម៉ូដែលមូលដ្ឋានទិន្នន័យដែលអនុញ្ញាតឲ្តមានការធ្វើបច្ចុប្បន្នភាព និងថែទាំមូលដ្ឋានច្បាប់ប្រកបដោយប្រសិទ្ធភាព ដោយប្រើប្រាស់ SQL Alchemy ជាឧបករណ៍ផ្ទុក។

២.៣ ប្រព័ន្ធជំនួយការសម្រេចចិត្តកសិកម្មតាមប្រព័ន្ធបណ្ដាញ (Agricultural Decision Support System)

ប្រព័ន្ធជំនួយការសម្រេចចិត្តកសិកម្ម (ADSS) ដែលផ្អែកលើបណ្ដាញបានផ្ដល់នូវភាពងាយស្រួលនៃការចូលប្រើប្រាស់ និងលទ្ធភាពធ្វើមាត្រដ្ឋានខ្ពស់។ ការសិក្សាជាច្រើនបានប្រើប្រាស់ Web Frameworks ដូចជា Flask, Django ឫ Spring Boot ដើម្បីបង្កើតផ្នែកខាងមុខ (Frontend) និងភ្ជាប់ទៅសេវាវេជ្ជសាស្រ្ត។ Flask ត្រូវបានគេពេញចិត្តជាពិសេសសម្រាប់ការអភិវឌ្ឍប្រព័ន្ធជំនាញដែលមានទំហំតូចទៅមធ្យមដោយសារតែភាពសាមញ្ញ និងភាពបត់បែនរបស់វា។
ការស្ទង់មតិបង្ហាញថា ខណៈពេលដែលប្រព័ន្ធ ADSS តាមបណ្ដាញមានលក្ខណៈទូទៅ ការរួមបញ្ចូលរវាងម៉ាសីុនវែកញែកផ្អែកលើច្បាប់ដ៍ស្មុគស្មាញ (rule-based inference engine) ជាមួយនឹងស្ថាបត្យកម្ម MVS សុវត្ថិភាពគឺមិនទាន់ត្រូវបានអនុវត្តយ៉ាងល្អឥតខ្ចោះទេ។ ការធានាសុវត្តិភាពទិន្នន័យ (Data Security) និងការគ្រប់គ្រងអ្នកប្រើប្រាស់ (User Management) គឺជាកង្វល់ចម្បង់ដែលត្រូវការការយកចិត្តទុកដាក់ក្នុងការអភិវឌ្ឍន៍។

២.៤ ចន្លោះប្រហោងនៃការស្រាវជ្រាវ (Research Gap)

ទោះបីជាមានការខិតខំប្រឹងប្រែងពីមុនក៏ដោយ ប្រព័ន្ធជំនាញដែលមានស្រាប់តែបរាជ័យក្នុងការដោះស្រាយបញ្ហាចម្បងមួយចំនួន។ ប្រព័ន្ធទាំងនោះជារឿយៗខ្វះមុខងារគ្រប់គ្រង់លំហូរការងារ (workflow management) សម្រាប់អ្នកជំនាញផ្នែកដែន (Domain Experts) ដើម្បីបញ្ចូល និងកែប្រែមូលដ្ឋានច្បាប់ដោយផ្ទាល់។ លើសពីនេះ ប្រព័ន្ធជាច្រើនផ្ដោតលើតែការវិនិច្ឆ័យប៉ុណ្ណោះ ហើយមិនរាប់បញ្ចូលម៉ូដែលសន្តិសុខផ្អែកលើតួនាទី (role-based security model) ដែលរឹងមាំនោះទេ។
ការស្រាវជ្រាវនេះមានគោលបំណងបំពេញចន្លោះប្រហោងនេះដោយការរចនាប្រព័ន្ធដែលអាចពង្រីកបាន ដែលគាំទ្រការគ្រប់គ្រងចំណេះដឹងយ៉ាងសកម្មដោយអ្នកជំនាញ។ ការងាររបង់យើងផ្តោតលើការរួមបញ្ចូលគ្នានៃម៉ាសុីនវិនិច្ឆ័យដែលមានប្រសិទ្ធភាពជាមួយ ប្រព័ន្ធគ្រប់គ្រង់មូលដ្ឋានទិន្នន័យ Flask/SQL Alchemy ដែលមានសុវត្ថិភាព និងងាយស្រួលប្រើប្រាស់។ 

៣. វិធីសាស្ត្រស្រាវជ្រាវ និងអភិវឌ្ឍន៍ (RESEARCH AND DEVELOPMENT METHODOLOGY)

៣.១ ទិដ្ឋភាពទូទៅ និងស្ថាបត្យកម្មប្រព័ន្ធ(System Overview and Architecture)

ប្រព័ន្ធនេះត្រូវបានបង្កើតឡើងដោយប្រើស្ថាបត្យកម្ម Model-View-Controller (MVC) ដែលផ្តល់នូវភាពបត់បែននិងការថែទាំកូដបានល្អប្រសើរ។ ស្ថាបត្យកម្មនេះបែងចែកកម្មវិធីជាបីផ្នែក៖ Model (គ្រប់គ្រងទិន្នន័យ), View(គ្រប់គ្រងចំណុចប្រទាក់អ្នកប្រើប្រាស់),និងController(គ្រប់គ្រងតក្កវិជ្ជាកម្មវិធី)។

ផ្នែកសំខាន់ៗនៃស្ថាបត្យកម្មប្រព័ន្ធរួមមាន៖

១.ចំណុចប្រទាក់អ្នកប្រើប្រាស់ (User Interface/View): ទទួលការបញ្ចូលរោគសញ្ញាពីអ្នកប្រើប្រាស់។

២.កម្មវិធីបញ្ជាFlask (Flask Controllers): ដើរតួជាស្រទាប់តក្កវិជ្ជាកម្មវិធី ដោយទទួលបានសំណើពីអ្នកប្រើប្រាស់និងបញ្ជូនពួកវាទៅកាន់ម៉ាសុីនច្បាប់។

៣.ម៉ាសុីនច្បាប់ (Rule Engine/Service): គឺជាបេះដូងនៃប្រព័ន្ធ ដែលដំណើរការការវែកញែកដោយប្រើច្បាប់ IF-THEN។

៤.មូលដ្ឋានចំណេះដឹង SQL Alchemy​​ (SQL Alchemy Knowledge Base/Model): ផ្ទុករោគសញ្ញា ជំងឺ ច្បាប់វិនិច្ឆ័យ និងទិន្នន័យអ្នកប្រើប្រាស់ទាំងអស់។

រចនាសម្ព័ន្ធនេះអនុញ្ញាតឲមានការបែងចែកយ៉ាងច្បា់រវាងការបង្ហាញទិន្នន័យ និងតក្កវិជ្ជាដំណើរការ។

៣.២ ដំណើរការវិស្វកម្មចំណេះដឹង (Knowledge Engineering Process)

ភាពជោគជ័យនៃប្រព័ន្ធជំនាញនេះគឺអាស្រ័យលើគុណភាពនៃមូលដ្ឋានចំណេះដឹងនៃមូលដ្ឋានចំណេះដឹងរបស់វា។ ដំណើរការវិស្វកម្មចំណេះដឹងត្រូវបានអនុវត្តតាមដំណាក់កាលជាប្រប័ន្ធដូចខាងក្រោម៖

១. ការទាញយកចំណេះដឹង (Knowledge Acquisition)៖ ដំណាក់កាលនេះពាក់ព័ន្ធនឹងការស្រាវជ្រាវពីបណ្ដាញអីុនធឺណិត ដើម្បីកំណត់អត្តសញ្ញាណរោគសញ្ញាសំខាន់ៗ ទំនាក់ទំនងរវាងរោគសញ្ញា និងជំងឺ និងកម្រិតទំនុកចិត្តដែលពាក់ព័ន្ធ។

២. ការបង្កើតគំរូចំណេះដឹង (Knowledge Modeling)៖ ចំណេះដឹងដែលបានទាញយកត្រូវបានរៀបចំទៅជាគំនិតច្បាស់លាស់ ដោយកំណត់អង្គភាពសំខាន់ៗ (រោគសញ្ញា ជំងឺ ច្បាប់) និងទំនាក់ទំនងរបស់ពួកគេ។

៣. តំណាងចំណេះដឹង (Knowledge Representation)៖ ចំណេះដឹងត្រូវបានបកប្រែទៅជាទម្រង់ដែលអាចអានបានដោយម៉ាសុីន។ ក្នុងករណីនេះ វាត្រូវបានរក្សាទុកជាច្បាប់ IF-THEN ដែលត្រូវបានបញ្ចូលទៅក្នុងតារាងសមស្របនៅក្នុងមូលដ្ឋានទិន្នន័យ។

៤. ការផ្ទៀងផ្ទាត់ (Validation)៖ ច្បាប់ និងលទ្ធផលដែលបានបង្កើតឡើងត្រូវបានធ្វើតេស្តម្ដងទៀតជាមួយអ្នកជំនាញផែ្នកដែន ដើម្បីធានាបាននូវភាពត្រឹមត្រូវ និងភាពសុីសង្វាក់គ្នានៃការវិនិច្ឆ័យមុនពេលអនុវត្តចុងក្រោយ។

៣.៣. គំរូ ERD តាមគំនិត (Conceptual ERD Model-High-Level)

គំរូ ERD តាមគំនិតបានផ្ដល់នូវទិដ្ឋភាពទូទៅនៃអង្គភាពសំខាន់ៗ (Entities) និងទំនាក់ទំនងរបស់ពួកគេ ដោយមិនចាំបាច់មានព័តិមានលម្អិតអំពីលក្ខណៈសម្បត្តិ (Attributes) នោះទេ។

A.    អង្គភាព (Entities):

·      Diseases: តំណាងឱ្យជំងឺដែលអាចកើតមានលើផ្កាឈូករ័ត្ន និងព័ត៌មានលម្អិតអំពីវិធីព្យាបាល។

·      SymptomChecks: តំណាងឱ្យព្រឹត្តិការណ៍នៃការឆែករោគសញ្ញា (កត់ត្រាថាអ្នកណាជាអ្នកឆែក និងឆែកនៅពេលណា)។

·      Users: តំណាងឱ្យអ្នកប្រើប្រាស់ផ្សេងៗគ្នា (អ្នកគ្រប់គ្រង-Admin, អ្នកជំនាញ-Doctor, អ្នកប្រើប្រាស់ធម្មតា-User)។

·      Feedback: តំណាងឱ្យការផ្ដល់មតិ ឬការសាកសួររបស់អ្នកប្រើប្រាស់មកកាន់ប្រព័ន្ធ។

·      SymptomCheckSymptoms: តំណាងឱ្យរោគសញ្ញាជាក់លាក់ដែលអ្នកប្រើប្រាស់បានជ្រើសរើស ក្នុងអំឡុងពេលធ្វើការវិនិច្ឆ័យម្តងៗ (ជាអ្នកភ្ជាប់រវាងការឆែក និងបញ្ជីរោគសញ្ញា)។

·      Roles: តំណាងឱ្យតួនាទីក្នុងប្រព័ន្ធ (ឧទាហរណ៍៖ Admin, Doctor, User)។

·      Permissions: តំណាងឱ្យសិទ្ធិជាក់លាក់ក្នុងការចូលប្រើមុខងារនីមួយៗ (ឧទាហរណ៍៖ សិទ្ធិលុបទិន្នន័យ, សិទ្ធិកែប្រែព័ត៌មាន)។

·      RolePermissions: តំណាងឱ្យការកំណត់សិទ្ធិទៅឱ្យតួនាទីនីមួយៗ (ជាអ្នកកំណត់ថា Role មួយណា មានសិទ្ធិធ្វើអ្វីខ្លះ)។

·      SymptomCheckResults: តំណាងឱ្យលទ្ធផលវិនិច្ឆ័យដែលប្រព័ន្ធគណនាបាន (កត់ត្រាទុកនូវបញ្ជីជំងឺដែលសង្ស័យ និងភាគរយ % នៃភាពជឿជាក់សម្រាប់រក្សាទុកក្នុងប្រវត្តិនៃការឆែក)។

B. ទំនាក់ទំនងរវាងអង្គភាពទិន្នន័យ (Relationship between Entities)

នៅក្នុងប្រព័ន្ធជំនាញវិនិច្ឆ័យជំងឺផ្កាឈូករ័ត្ននេះ ទំនាក់ទំនងរវាង Entity សំខាន់ៗត្រូវបានកំណត់ដូចខាងក្រោម៖

·       User និង SymptomChecks (One-to-Many): អ្នកប្រើប្រាស់ម្នាក់ (User) អាចធ្វើការឆែករោគសញ្ញាបានច្រើនដង ប៉ុន្តែការឆែករោគសញ្ញានីមួយៗត្រូវកំណត់អត្តសញ្ញាណដោយអ្នកប្រើប្រាស់តែម្នាក់គត់។

·       SymptomChecks និង SymptomCheckSymptoms (One-to-Many): ក្នុងការឆែករោគសញ្ញាម្តងៗ អាចមានរោគសញ្ញាជាច្រើនដែលត្រូវបានជ្រើសរើស (Selected Symptoms)។

·       SymptomChecks និង SymptomCheckResults (One-to-Many): បន្ទាប់ពីឆ្លងកាត់ម៉ាស៊ីនវិនិច្ឆ័យ (Inference Engine) ការឆែកម្តងអាចទទួលបានលទ្ធផលជាជំងឺច្រើនប្រភេទដែលសង្ស័យ (Ranked Results)។

·       User និង Feedback (One-to-Many): អ្នកប្រើប្រាស់ម្នាក់អាចផ្ញើមតិត្រឡប់ ឬសំណួរបានច្រើនសារទៅកាន់ប្រព័ន្ធ។

·       Roles និង Permissions (Many-to-Many): តួនាទីមួយ (Role) អាចមានសិទ្ធិ (Permissions) ច្រើន ហើយសិទ្ធិមួយក៏អាចប្រើដោយតួនាទីច្រើនដែរ។ ទំនាក់ទំនងនេះត្រូវបានភ្ជាប់តាមរយៈតារាងកណ្តាលគឺ RolePermissions។

·       Users និង Roles (Many-to-One): អ្នកប្រើប្រាស់ម្នាក់ៗត្រូវបានកំណត់ឱ្យស្ថិតក្នុងតួនាទីណាមួយជាក់លាក់ (ដូចជា Admin, Doctor, ឬ User) ដើម្បីកំណត់ដែនសមត្ថកិច្ចក្នុងការប្រើប្រាស់ប្រព័ន្ធ។

៣.៤. គំរូ ERD តាមតក្កវិជ្ជា (Logical ERD Model - Detailed)

គំរូ ERD តាមតក្កវិជ្ជាផ្ដល់នូវព័តិមានលម្អិតអំពីលក្ខណៈសម្បត្តិ (Attributes) គន្លឹះបឋម (PK) គន្លឹះបរទេស (FK) និងលក្ខណៈទំនាក់ទំនង (Cardinalities) សម្រាប់អង្គភាពនីមួយៗដោយបង្កើតជាមូលដ្ឋានគ្រឹះសម្រាប់គ្រោងការណ៍ SQL Alchemy។

Diseases (តារាងព័ត៌មានជំងឺ និងភ្នាក់ងារបង្កជំងឺ):
id (PK), slug, pathogen_type, image_media_id (FK), is_published, search_vector, created_by_id (FK), created_at, updated_at
SymptomCategories (តារាងប្រភេទផ្នែករុក្ខជាតិ - ស្លឹក, ដើម, ផ្កា, ឫស):
id (PK), code, sort_order
Symptoms (តារាងកាតាឡុកសូចនាកររោគសញ្ញា):
id (PK), code, category_id (FK), is_environmental, created_by_id (FK), created_at, updated_at
DiseaseSymptoms (តារាងភ្ជាប់ជំងឺនិងរោគសញ្ញា ព្រមទាំងទម្ងន់ពិន្ទុ):
disease_id (PK/FK), symptom_id (PK/FK), weight, is_pathognomonic, is_required
Rulesets (តារាងកំណត់ក្បួនវិធាន និងប៉ារ៉ាម៉ែត្រម៉ាស៊ីនវិនិច្ឆ័យ AI):
id (PK), version, algorithm, params, is_active, published_at, published_by_id (FK)
Translations (តារាងបកប្រែពហុភាសា ភាសាខ្មែរ និង អង់គ្លេស):
id (PK), entity_type, entity_id, locale, field, value
DiagnosisSessions (តារាងរក្សាទុកវគ្គនៃការពិនិត្យរោគសញ្ញា):
id (PK), user_id (FK), ruleset_id (FK), locale, outcome, feedback_prompt, created_at
DiagnosisSelectedSymptoms (តារាងរក្សារោគសញ្ញាដែលអ្នកប្រើបានរើស Yes/No/Unknown):
session_id (PK/FK), symptom_id (PK/FK), answer
DiagnosisResults (តារាងរក្សាទុកលទ្ធផល និងភស្តុតាងដែលម៉ាស៊ីនវិនិច្ឆ័យបាន):
id (PK), session_id (FK), disease_id (FK), rank, score, confidence, evidence
Users (តារាងគណនីអ្នកប្រើប្រាស់):
id (PK), email, username, hashed_password, role_id (FK), is_active, created_at, updated_at
Roles (តារាងតួនាទី - Admin, Expert, Farmer):
id (PK), name, description
Permissions (តារាងសិទ្ធិអនុញ្ញាតក្នុងប្រព័ន្ធ):
id (PK), code, description
RolePermissions (តារាងកណ្តាលភ្ជាប់ Role និង Permission):
role_id (PK/FK), permission_id (PK/FK)
Media (តារាងផ្ទុកព័ត៌មានរូបភាពជំងឺ):
id (PK), filename, file_path, mime_type, file_size, uploaded_by_id (FK), created_at
Feedback (តារាងមតិកែលម្អ និងការវាយតម្លៃរបស់អ្នកប្រើប្រាស់):
id (PK), session_id (FK), user_id (FK), rating, comment, contact_email, created_at
AuditLog (តារាងកត់ត្រាសកម្មភាព និងសុវត្ថិភាពរបស់ប្រព័ន្ធ):
id (PK), user_id (FK), action, entity_type, entity_id, changes, ip_address, created_at

៣.៥ រចនាសម្ព័ន្ធគម្រោង Flask MVC (Flask MVC Project Structure) 

រចនាសម្ព័ន្ធគម្រោងត្រូវបានរៀបចំឡើង ដើម្បីធានាបាននូវការបែងចែកភារកិច្ច (Separation of Concerns) ដោយអនុវត្តតាមស្ថាបត្យកម្ម MVC ។
ក្នុងគម្រោងនេះ Flask ត្រូវបានប្រើសម្រាប់គ្រប់គ្រងផ្លូវ (Routes) និងវត្ថុបញ្ជា (Controller) ខណៈពេលដែល SQL Alchemy គ្រប់គ្រងទិន្នន័យ។

Expert_sunflower-deploy/
│
├── docker-compose.yml # Multi-container orchestration (DB, pgAdmin, API, Web)
├── .env # Application configurations & DB credentials
│
├── backend/ # Backend API & AI Inference Engine (FastAPI)
│ ├── app/
│ │ ├── api/v1/routes/ # Route handlers & controllers (Endpoints)
│ │ ├── models/ # Database schema models (Diseases, Symptoms, Rules)
│ │ ├── schemas/ # Data validation & DTOs (Pydantic models)
│ │ ├── repositories/ # Database queries & data access layer
│ │ ├── services/
│ │ │ └── engine/ # Core AI Diagnostic Inference Engine
│ │ │ ├── scoring.py # Rule evaluation & weighted scoring math
│ │ │ ├── next_question.py# Information gain & next best questions logic
│ │ │ ├── explain.py # Explainability evidence builder (supporting/opposing)
│ │ │ └── runner.py # Diagnostic session runner & DB coordinator
│ │ ├── core/ # Security, JWT auth, rate limiting & error handling
│ │ └── db/ # Async database connection & session setup
│ ├── alembic/ # Database version control & migration scripts
│ ├── scripts/
│ │ └── seed_20_diseases_and_symptoms.sql # SQL seed script (20 diseases, 62 symptoms)
│ ├── Dockerfile # Container definition for backend service
│ └── pyproject.toml # Backend dependencies list
│
├── frontend/ # Frontend Web UI (React 19 + TypeScript + Vite)
│ ├── src/
│ │ ├── assets/images/Sunflower/# Clinical field photos & disease reference library
│ │ ├── components/ # Reusable UI widgets & glassmorphic layout
│ │ ├── features/
│ │ │ ├── landing/ # Home page & live metrics banner
│ │ │ ├── diagnosis/ # Interactive symptom checker & diagnosis results
│ │ │ ├── diseases/ # Disease catalog, detail page & photo gallery
│ │ │ └── admin/ # Admin dashboard, audit logs & analytics charts
│ │ ├── locales/ # Multi-language translation files (en.json, km.json)
│ │ ├── api/ # HTTP client for connecting to backend API
│ │ ├── router.tsx # Application page routing
│ │ ├── main.tsx # Frontend application entrypoint
│ │ └── App.tsx # Root UI component wrapper
│ ├── Dockerfile # Container definition for frontend service
│ └── package.json # Frontend dependencies & build scripts
│
└── database/
└── PostgreSQL 16 # Relational DB (sunflower_db on port 5433)

៤. លទ្ធផល(Results)

ផ្នែកនេះបង្ហាញលទ្ធផលជាក់ស្តែងនៃការអនុវត្តន៍ប្រព័ន្ធជំនាញវិនិច្ឆ័យរោគសញ្ញា ដោយផ្តោតលើគ្រោងការណ៍មូលដ្ឋានទិន្នន័យ(Database Schema) ការអនុវត្តសុវត្ថិភាព​​(Security Implementation) និងឧទាហរណ៍នៃការគ្រប់គ្រងចំណេះដឹង(Knowledge Management) តាមរយៈ SQL Alchemy។

៤.១. គ្រោងការណ៍មូលដ្ឋានទិន្នន័យជាក់ស្តែង (Physical Database Schema - SQL DDL)

នៅក្នុងការអនុវត្តប្រព័ន្ធជំនាញវិនិច្ឆ័យជំងឺផ្កាឈូករ័ត្ននេះ យើងបានប្រើប្រាស់ប្រព័ន្ធគ្រប់គ្រងមូលដ្ឋានទិន្នន័យ Postgre SQL ដើម្បីរក្សាទុកចំណេះដឹងពីអ្នកជំនាញ។

៤.១.១. សេចក្តីថ្លែងការណ៍ (Code Create Table) 

រចនាសម្ព័ន្ធតារាងត្រូវបានបង្កើតឡើងដោយប្រើប្រាស់ SQL Alchemy Model ដែលមានលក្ខណៈសមមូលទៅនឹង SQL DDL ដូចខាងក្រោម៖

SQL

CREATE TABLE diseases (

    id INTEGER PRIMARY KEY AUTO_INCREMENT,

    slug VARCHAR(80) UNIQUE NOT NULL,

    name VARCHAR(120) NOT NULL,

    symptoms TEXT NOT NULL,

    treatment TEXT NOT NULL,

    prevention TEXT NOT NULL,

    symptom_checklist_json TEXT DEFAULT '[]' -- រក្សទុករោគសញ្ញាសម្រាប់ Rule Engine

);

CREATE TABLE users (

    id INTEGER PRIMARY KEY AUTO_INCREMENT,

    username VARCHAR(80) UNIQUE NOT NULL,

    email VARCHAR(120) UNIQUE NOT NULL,

    password_hash VARCHAR(255) NOT NULL,

    role VARCHAR(20) DEFAULT 'user' -- user, doctor, admin

);

៤.២. ការអនុវត្តសុវត្ថិភាព (Security Implementation)

សុវត្ថិភាពត្រូវបានអនុវត្តតាមរយៈការត្រួតពិនិត្យការចូលប្រើប្រាស់ដោយផ្អែកលើតូនាទី(Role-Based Access Control- RBAC) ដើម្បីធានាថាអ្នកចូលប្រើម្នាក់ៗមានសិទ្ធិចូលប្រើតែមុខងារដែលចាំបាច់សម្រាប់តួនាទីរបស់ខ្លួនតែប៉ុណ្ណោះ។

៤.២.១. ការត្រួតពិនិត្យការចូលប្រើប្រាស់ផ្អែកលើតួនាទី (Role Based Access Control - RBAC)ប្រព័ន្ធប្រើប្រាស់យន្តការ Decorator ក្នុង app/utils.py ដើម្បីការពារ Route នីមួយៗតាមរយៈការឆែក Permission៖

Admin: មានសិទ្ធិ access_admin, manage_users និង view_symptom_checks។

Doctor: មានសិទ្ធិ manage_diseases ក្នុងការពង្រីកមូលដ្ឋានចំណេះដឹង។

User: មានសិទ្ធិ use_symptom_checker និង edit_own_profile។

៤.២.២. ឧទាហរណ៍តក្កវិទ្យានៃសុវត្ថិភាពកម្រិតជួរដេក (Row-Level Security Logic Example)នៅក្នុង Model User.py មាន Logic សម្រាប់ផ្ទៀងផ្ទាត់សិទ្ធិបុគ្គលលើទិន្នន័យ៖

def has_permission(self, permission_name):

    if self.role == "admin": 

        return True 

    return any(p.name == permission_name for p in self.role_obj.permissions)

៤.៣. ឧទាហរណ៍នៃការបញ្ចូលទិន្នន័យ (Sample Code Inserts) 

ការបញ្ចូលទិន្នន័យគំរូនៃជំងឺផ្កាឈូករ័ត្នត្រូវបានធ្វើឡើងតាមរយៈ Script seed.py៖

disease_entry = Disease(

    name="Sunflower Rust",

    slug="sunflower-rust",

    symptom_checklist_json='[{"key": "orange_pustules", "label": "Orange/brown rust pustules"}]',

    treatment="Apply appropriate fungicides.",

    prevention="Plant resistant hybrids."

)

db.session.add(disease_entry)

db.session.commit()

៤.៤. ឧទាហរណ៍នៃការធ្វើបច្ចុប្បន្នភាព និងការលុបទិន្នន័យ (Sample Update and Delete Code) មុខងារកែសម្រួល និងលុបត្រូវបានដាក់ឱ្យប្រើប្រាស់ក្នុងផ្នែកអភិបាល (Admin/Doctor Dashboard)៖

disease = Disease.query.get(id)

disease.name = request.form.get('name')

db.session.commit()

user_to_delete = User.query.get(id)

db.session.delete(user_to_delete)

db.session.commit()

៤.៥. សំណួរ Select ស្មុគស្មាញ (Complex SELECT Queries)

សំណួរស្មុគស្មាញទាំងនេះត្រូវបានប្រើប្រាស់ដោយម៉ាស៊ីន(Rule Engine) ដើម្បីទាញយកទិន្នន័យសម្រាប់ការវិនិច្ឆ័យនិងសម្រាប់របាយការណ៍ប្រព័ន្ធ។

៤.៥.១. Multi-join សម្រាប់វែកញែកផ្អែកលើច្បាប់ (Multi-join​​​ for Rule-Based Reasoning)

 ក្នុង app/services/diagnosis_db.py ប្រើប្រាស់ Query ដើម្បីទាញយកទិន្នន័យមកគណនា Score៖

diseases = Disease.query.order_by(Disease.name.asc()).all()

៤.៥.២. ប្រវត្តិពិគ្រោះនៃអ្នកប្រើប្រាស់ (Consultation History with User Information) 

ការបង្ហាញរបាយការណ៍សង្ខេបសម្រាប់ Admin ប្រើប្រាស់ការ Join រវាងតារាង SymptomCheck និង User៖

recent_checks = (

    SymptomCheck.query

    .join(User, SymptomCheck.user_id == User.id)

    .filter(User.role != "admin")

    .order_by(SymptomCheck.created_at.desc())

    .limit(10).all()

)

៥. ការពិភាក្សា (DISCUSSION)

ផ្នែកនេះវាយតម្លៃលើការអនុវត្តប្រព័ន្ធដែលបានអភិវឌ្ឍ និងពិភាក្សាអំពីភាពខ្លាំង ដែនកំណត់ និងការរួមចំណែករបស់វាធៀបនឹងការងារស្រាវជ្រាវដែលមានស្រាប់ ។

៥.១ ការអនុវត្តប្រព័ន្ធ និងភាពត្រឹមត្រូវ (System Performance and Accuracy)

Expert System សម្រាប់វិនិច្ឆ័យជំងឺផ្កាឈូករ័ត្នដែលបានអភិវឌ្ឍដោយប្រើ Flask និង SQL Alchemy បានបង្ហាញនូវលទ្ធផលគួរឱ្យកត់សម្គាល់ ។ ភាពត្រឹមត្រូវនៃ Diagnosis Accuracy ត្រូវបានវាយតម្លៃដោយការប្រៀបធៀបលទ្ធផលរបស់ប្រព័ន្ធ ជាមួយនឹងការវិនិច្ឆ័យជាក់ស្តែងពីការស្រាវជ្រាវលើសំណុំទិន្នន័យនៃជំងឺផ្កាឈូករ័ត្ន (ដូចជា Rust និង Downy Mildew) ។ លទ្ធផលបង្ហាញថា ប្រព័ន្ធសម្រេចបាននូវ Rule Coverage ខ្ពស់ ដែលអនុញ្ញាតឱ្យកសិករទទួលបានការណែនាំបានយ៉ាងត្រឹមត្រូវ ។ ចំពោះផ្នែកនៃការបង្ហាញលទ្ធផលប្រព័ន្ធផ្តល់នូវ ការសន្និដ្ឋានឆាប់រហ័សបំផុត ដោយសារប្រសិទ្ធភាពនៃការទាញយកទិន្នន័យពី SQL Alchemy ។

៥.២ ភាពខ្លាំង និងការរួមចំណែក (Strengths and Limitations)

ក. ភាពខ្លាំង (Strengths)

• ស្ថាបត្យកម្មទំនើប: ចំណុចលេចធ្លោនៃប្រព័ន្ធនេះគឺការប្រើប្រាស់ស្ថាបត្យកម្ម MVC (Model-View-Controller) រួមជាមួយ SQL Alchemy ORM ដែលផ្តល់នូវភាពងាយស្រួលក្នុងការពង្រីក (Scalability) និងការថែទាំប្រព័ន្ធ។
• ចំណេះដឹងមានភាពរស់រវើក (Dynamic Knowledge Base): ប្រព័ន្ធបានដោះស្រាយនូវ Research Gap ដោយការរួមបញ្ចូលនូវRole-Based Access Control (RBAC)។ មិនដូចប្រព័ន្ធវិនិច្ឆ័យទូទៅដែលមានច្បាប់ថេរ (Static) នោះទេ ប្រព័ន្ធរបស់យើងអនុញ្ញាតឱ្យអ្នកជំនាញ (Doctor) ធ្វើបច្ចុប្បន្នភាពរោគសញ្ញាតាមរយៈ JSON-based checklist បានភ្លាមៗ (Real-time update) ដែលធ្វើឱ្យការវិនិច្ឆ័យតែងតែទាន់សម័យ។

ខ. ដែនកំណត់ (Limitations)

• Subjective Inputs: ភាពត្រឹមត្រូវនៃការព្យាករណ៍អាស្រ័យយ៉ាងខ្លាំងលើការបញ្ចូលទិន្នន័យរបស់អ្នកប្រើប្រាស់។ ប្រសិនបើអ្នកប្រើប្រាស់កំណត់រោគសញ្ញាមិនច្បាស់លាស់ វានឹងប៉ះពាល់ដល់ Confidence Score។
• Rule-Based Limitation: ដោយសារប្រព័ន្ធផ្អែកលើ Rule-Based Reasoning វាមិនអាច "រៀន" ដោយខ្លួនឯងដូចប្រព័ន្ធ Machine Learning ឡើយ។ វាអាចវិនិច្ឆ័យបានតែជំងឺណាដែលមានច្បាប់ចែងទុកក្នុង Knowledge Base ប៉ុណ្ណោះ។
• Environmental Factors: បច្ចុប្បន្ន ប្រព័ន្ធផ្ដោតលើតែរោគសញ្ញាមើលឃើញ (Visual Symptoms) ប៉ុន្តែមិនទាន់បានរួមបញ្ចូលទិន្នន័យបរិស្ថាន ដូចជា កម្រិត pH ដី ឬអាកាសធាតុ ដែលជាកត្តាសំខាន់នៃជំងឺផ្កាឈូករ័ត្ននៅឡើយទេ។

៥.៣ ការប្រៀបធៀបជាមួយប្រព័ន្ធដែលមានស្រាប់ (Comparison with Existing Systems)

នៅក្នុងការសិក្សាប្រៀបធៀបនេះឃើញថា ប្រព័ន្ធជំនាញវិនិច្ឆ័យជំងឺផ្កាឈូករ័ត្នដែលបានអភិវឌ្ឍមានលក្ខណៈពិសេសលើសពីប្រព័ន្ធដែលមានស្រាប់ត្រង់ការផ្តោតលើដែនចំណេះដឹងជាក់លាក់ (Specific Domain Expertise) ដែលផ្តល់នូវព័ត៌មានរោគសញ្ញាស៊ីជម្រៅជាងប្រព័ន្ធកសិកម្មទូទៅ។ ភាពខុសគ្នាជាយុទ្ធសាស្ត្រមួយទៀតគឺការប្រើប្រាស់ស្ថាបត្យកម្ម Web-Based តាមរយៈ Flask ដែលផ្តល់នូវលទ្ធភាពចូលប្រើប្រាស់បានយ៉ាងងាយស្រួលពីគ្រប់ទីកន្លែង ខុសពីប្រព័ន្ធជំនាញជំនាន់មុនដែលជាប្រភេទ Standalone Application។ លើសពីនេះ ការគ្រប់គ្រងមូលដ្ឋានចំណេះដឹងមានលក្ខណៈឌីណាមិក (Dynamic Knowledge Management) ដោយសារការប្រើប្រាស់ SQL Alchemy ដែលអនុញ្ញាតឱ្យអ្នកជំនាញធ្វើបច្ចុប្បន្នភាពច្បាប់វិនិច្ឆ័យបានភ្លាមៗដោយមិនចាំបាច់កែប្រែកូដប្រព័ន្ធ (Source Code) ដូចករណីប្រព័ន្ធ Static Rule Bases ឡើយ។ ជាចុងក្រោយ ការដាក់បញ្ចូលនូវគំរូសន្តិសុខ RBAC (Role-Based Access Control) បានបង្កើនភាពជឿជាក់ និងសុវត្ថិភាពក្នុងការគ្រប់គ្រងទិន្នន័យ ដែលជាចំណុចខ្វះខាតជារឿយៗត្រូវបានមើលរំលងនៅក្នុងការស្រាវជ្រាវពាក់ព័ន្ធផ្សេងៗកន្លងមក។

៦. សេចក្តីសន្និដ្ឋាន និងការងារនាពេលអនាគត (CONCLUSION AND FUTURE WORK)

៦.១ សេចក្តីសន្និដ្ឋាន (Conclusion)

ការស្រាវជ្រាវនេះបានសម្រេចដោយជោគជ័យនូវការរចនា និងការអភិវឌ្ឍ Web-Based Expert System សម្រាប់វិនិច្ឆ័យរោគសញ្ញាជំងឺលើដំណាំផ្កាឈូករ័ត្ន ដោយប្រើប្រាស់ Flask Framework និង SQL Alchemy ។ ប្រព័ន្ធនេះបានប្រើប្រាស់វិធីសាស្ត្រ Rule-Based Reasoning ដែលផ្អែកលើចំណេះដឹងពីអ្នកជំនាញកសិកម្ម ដើម្បីផ្តល់នូវការវិនិច្ឆ័យបឋមលើជំងឺសំខាន់ៗដូចជា Downy Mildew, Rust, និង Sclerotinia ជាដើម ។

តាមរយៈការធ្វើតេស្តពិសោធន៍ លទ្ធផលបង្ហាញថាប្រព័ន្ធមានភាពត្រឹមត្រូវ (Accuracy) ខ្ពស់ក្នុងការកំណត់អត្តសញ្ញាណជំងឺ តាមរយៈការបញ្ចូលរោគសញ្ញាដែលមើលឃើញដោយភ្នែក (Visual Symptoms) ។ ការប្រើប្រាស់ស្ថាបត្យកម្ម MVC និងការរៀបចំ Database Schema ដែលមានប្រសិទ្ធភាព បានអនុញ្ញាតឱ្យប្រព័ន្ធដំណើរការបានយ៉ាងរហ័ស និងងាយស្រួលក្នុងការគ្រប់គ្រង Knowledge Base ។ សរុបមក ប្រព័ន្ធនេះគឺជាឧបករណ៍ដ៏មានសារៈសំខាន់សម្រាប់កសិករក្នុងការការពារ និងព្យាបាលជំងឺលើផ្កាឈូករ័ត្នបានទាន់ពេលវេលា ។

៦.២ ការងារនាពេលអនាគត (Future Work)

ទោះបីជាប្រព័ន្ធសម្រេចបានលទ្ធផលល្អក៏ដោយ ក៏នៅមានចំណុចមួយចំនួនដែលអាចកែលម្អបន្ថែមនាពេលអនាគតរួមមាន៖

- Image Recognition Integration: បន្ថែមសមត្ថភាពដល់ប្រព័ន្ធឱ្យអាចវិនិច្ឆ័យជំងឺតាមរយៈការស្កេនរូបភាពស្លឹក ឬផ្កាឈូករ័ត្នដោយប្រើបច្ចេកវិទ្យា Deep Learning (CNN) ជាជាងការជ្រើសរើសរោគសញ្ញាតាមរយៈអត្ថបទតែមួយមុខ ។

- Mobile Application: អភិវឌ្ឍប្រព័ន្ធឱ្យទៅជាកម្មវិធីទូរស័ព្ទដៃ (Native Mobile App) ដើម្បីឱ្យកសិករអាចប្រើប្រាស់បានដោយផ្ទាល់នៅតាមវាលស្រែ ទោះបីជាគ្មានសេវាអ៊ីនធឺណិត (Offline Mode) ។

- Multilingual Support: បន្ថែមមុខងារគាំទ្រច្រើនភាសា ដើម្បីពង្រីកលទ្ធភាពប្រើប្រាស់ដល់កសិករក្នុងតំបន់ផ្សេងៗគ្នា ។

ឯកសារយោង (References)

[1] The Lightweight Deep Learning Model in Sunflower Disease Identification: A Comparative Study/Liqian Zhang ,* and Xiao Wu 

[2] Plant Disease Detection using Deep Learning in Banana and Sunflower

[3]EXPERT-SYSTEM-FOR-AGRICULTURAL-EXTENSION-A-REVIEW-OF-RECENT-DEVELOPMENTS

[4] Online Symptoms and Diseases Management System

[5] Expert System Implementation for the Diagnosis of Skin Diseases Using Forward Chaining Method

[6] Coursera/What Is Agile? And When to Use It | Coursera

[7] Analysis and Design of Disease Diagnosis Systems and Patient Medicine Recommendations with Forward Chaining Method/Samuel Ryon Elkana1)*, Verri Kuswanto2) 1)2)Universitas Buddhi Dharma Jl. Imam Bonjol No.41. Karawaci Ilir, Tangerang, Indonesia 1)samuelryonelkana@gmail.com 2)verri.kuswanto@ubd.ac.id

[8] Design and Development of a Knowledge-Based System for Medical Diagnosis/Hiba Basem Ali Abu Kwaik and Samy S. Abu-Naser Department of Information Technology, Faculty of Engineering & Information Technology, Al-Azhar University, Gaza, Palestine

[9] INTELLIGENT SYSTEM FOR SOLVING PROBLEMS OF VETERINARY MEDICINE ON THE EXAMPLE OF DAIRY FARMS/Shopagulov Olzhas, Tretyakov Igor and Ismailova Aisulu Dept. of Information Systems, Kazakh Agro Technical University named after S. Seifullin, Nur-Sultan, Kazakhstan

[10] Identification of Some Sunflower Diseases Using Deep Convolutional Neural Networks/Hakkı Fırat Altınbilek1, Ünal Kızı

[11] Building A Symptom-Based Disease Diagnosis Web App with Flask and Machine Learning/M. Akshith Reddy1, V. Sai Manish Reddy2, K. Vamshi Goud3, E. Nithin Kumar4, Mr. Kumar Baradur5, Dr. M. Ramesh6

[12]​ Journal of Advanced Zoology ISSN: 0253-7214 Volume 44 Issue 03 Year 2023 Page 93:106 /Plant Disease Detection using Deep Learning in Banana and Sunflower Chetan H R1, Rajanna G S2*, Sreenivasa B R3*, Ganesh N Yallappa4

[13] Sunflower Diseases