डेटाबेस मॉडलिंग

मैंने दंत सोता के बारे में एक गीत लिखा था लेकिन क्या किसी के दांत साफ हो गए?

फ्रैंक ज़प्पा

जब हम दंत चिकित्सा कार्यालय के बारे में सोचते हैं, तो हमारा पहला जुड़ाव ड्रिल, दर्द और भय होता है। ठीक है, यह बुरा लगता है। दांतों की देखभाल के अलावा, एक दंत चिकित्सक के पास कई अन्य दायित्व होते हैं जो पेशेवर, कानूनी या दोनों होते हैं। उन सभी को उचित डेटा प्रबंधन की आवश्यकता है।

इस दस्तावेज़ीकरण आवश्यकता को पूरा करने के लिए, कई दंत चिकित्सा और चिकित्सा कार्यालय कागजी रिकॉर्ड का उपयोग करते हैं। हालांकि, धीरे-धीरे लेकिन निश्चित रूप से, 21 वीं सदी के डिजिटल रिकॉर्ड और प्रबंधन की ओर रुझान है।

दंत चिकित्सा कार्यालय के अंदर

दंत चिकित्सक के पास जाना कोई ऐसी चीज नहीं है जिसे हम आमतौर पर खुशी के साथ याद करते हैं। अगर हम भाग्यशाली होते, तो हम दर्द को चकमा देते लेकिन हमारे बटुए को शायद बुरी तरह से नुकसान हुआ। जब हम दंत चिकित्सक के कार्यालय में कदम रखते हैं, तो प्रक्रिया आमतौर पर इस प्रकार होती है:

• आप दोनों चिट-चैट की एक छोटी सी लड़ाई में शामिल होते हैं। (अक्सर अप्रिय क्योंकि आपने अपने दंत चिकित्सक से वादा किया था कि आप अगले सप्ताह उसके पास आएंगे और 2 साल बीत चुके हैं। फिर आप कहते हैं कि आप भूल गए, वह सहमत है, और सब कुछ फिर से ठीक है।)
• जब वह आपके पिछले उपचार रिकॉर्ड को देखता है तो आप कुर्सी पर बैठते हैं। वह पूछता है कि क्या पिछली मुलाकात के बाद से कुछ हुआ है और क्या आपके मेडिकल रिकॉर्ड में कोई अपडेट है।
• क्या गलत हुआ यह निर्धारित करने के लिए वह आपके मुंह के अंदर एक नज़र डालता है, और आपको बताता है कि क्या इसे ठीक करेगा।
• आप उसकी उपचार योजना से सहमत हो सकते हैं या कोई अन्य विकल्प चुन सकते हैं।
• कुछ महीने बाद, आपके चेहरे पर फिर से हॉलीवुड की मुस्कान है। यह जल्दी होता, लेकिन आप तब तक मुस्कुरा नहीं सकते थे जब तक कि आप अंततः अपने दंत चिकित्सा कार्य के बिल का पूरा भुगतान नहीं कर देते।

इस बिंदु पर, यहां तक ​​कि सबसे समर्पित डेटाबेस पेशेवर शायद नहीं सोच रहे हैं, 'वाह, काश इस अनुभव के लिए एक डेटा मॉडल होता!' . लेकिन वहाँ है, और यह जांच के लायक है। इसलिए हमने इसे नीचे प्रिंट किया है।

पेश है हमारा डेंटल ऑफिस डेटाबेस मॉडल

इस मॉडल के पीछे का विचार यह है कि जब तक हम पहली बार दंत चिकित्सक के कार्यालय में कदम रखते हैं, तब तक हर प्रक्रिया को कवर किया जाता है जब तक कि समस्या का समाधान नहीं हो जाता। इस मॉडल का भाग (user_account , status , user_has_status , role , user_has_role ) पिछले लेखों में प्रस्तुत और वर्णित किया गया था। हो सकता है कि भूमिकाएं और स्थितियां यहां अनावश्यक दिखें, लेकिन याद रखें कि इस अभ्यास में एनामनेसिस (रिकॉर्ड लेने), एक रिसेप्शनिस्ट, एक दंत छात्र, कई प्रशिक्षित दंत चिकित्सा सहायक, या यहां तक ​​​​कि एक विज़िटिंग विशेषज्ञ या एक हाइजीनिस्ट को संभालने के लिए एक नर्स भी शामिल हो सकती है। हालांकि, इस लेख में भुगतान विवरण पर विचार नहीं किया जाएगा।

दंत डेटाबेस में तालिकाएं

patient तालिका डेटाबेस में दो सबसे महत्वपूर्ण तालिकाओं में से एक है। यह मरीजों के डेटा को स्टोर करता है और मरीजों के दस्तावेजों और यात्राओं से जुड़ा होता है। mail . के अपवाद के साथ , तालिका में सभी विशेषताएँ अनिवार्य हैं:

• name - मरीज का नाम
• surname - मरीज का उपनाम
• identification_number - इस फ़ील्ड का उपयोग क्लाइंट की विशिष्ट आईडी को संग्रहीत करने के लिए किया जाता है जिसका उपयोग वास्तविक दुनिया में किया जाता है
• address - मरीज का पता
• phone - मरीज का फोन नंबर
• mail - मरीज का मेल पता

डेटाबेस में दूसरी सबसे महत्वपूर्ण तालिका है visit . तालिका के साथ संयुक्त होने पर patient , यह उस घटना के बारे में जानकारी संग्रहीत करता है जिसने बाद की सभी क्रियाओं को ट्रिगर किया। तालिका में विशेषताएँ हैं:

• visit_date - इसमें वास्तविक तिथि और समय होता है जब विज़िट हुई थी
• patient_id - क्या मरीज की उसकी यात्रा से संबंधित आईडी है
• dentist_id - user_has_role तालिका, यह मानते हुए कि भूमिका दंत चिकित्सक की है

अगला है anamnesis टेबल। चिकित्सा में, इतिहास एक ऐसी प्रक्रिया है जहां हम रोगी की वर्तमान स्थिति जैसे चिकित्सा डेटा इतिहास को एकत्रित और संग्रहीत करते हैं। anamnesis तालिका इस डेटा को संग्रहीत करती है। चूंकि यह कार्यालय में हमारे आगमन के तुरंत बाद होता है, इसलिए हमारे पास प्रति ईवेंट अधिकतम एक इतिहासलेख होगा। तालिका में विशेषताएँ हैं:

• anamnesis_id - anamnesis तालिका, जो visit टेबल
• user_anamnesis_id - यह user_has_role टेबल। ध्यान दें कि दंत चिकित्सक को एनामनेसिस करने वाला नहीं होना चाहिए।
• notes - विशिष्ट इतिहास के बारे में पाठ नोट्स शामिल हैं। यह अनिवार्य फ़ील्ड नहीं है।

anamnesis_type तालिका एक सरल शब्दकोश है जिसका उपयोग anamnesis_catalog . एकमात्र विशेषता type_name . है , और इसमें "बीमारी", "एलर्जी", "प्रयुक्त दवा" जैसे मान हो सकते हैं। बेशक, वह एकमात्र विशेषता अनिवार्य है।

anamnesis_catalog तालिका एक शब्दकोश है जो anamnesis_type टेबल। हम इसका उपयोग विशिष्ट बीमारी, एलर्जी और दवाओं के बारे में डेटा रखने के लिए करेंगे। सभी विशेषताएँ अनिवार्य हैं, और उनमें शामिल हैं:

• catalog_name - विशिष्ट anamnesis_type उपश्रेणी
• anamnesis_type_id - anamnesis_type टेबल

visit_anamnesis तालिका का उपयोग एनामनेसिस कैटलॉग के मूल्यों के साथ विज़िट डेटा को जोड़ने के लिए किया जाता है। तालिका में प्रत्येक विशेषता आवश्यक है:

• anamnesis_anamnesis_id - anamnesis टेबल
• anamnesis_catalog_id - anamnesis_catalog टेबल

ध्यान दें कि visit_anamnesis तालिका anamnesis और anamnesis_catalog . इस जोड़ी को स्टोर करने का कोई मतलब नहीं है (anamnesis_anamnesis_id &anamnesis_catalog_id ) दो बार। हम उस जोड़ी को प्राथमिक कुंजी के रूप में उपयोग करेंगे।

document तालिका एक साधारण कैटलॉग है जिसमें ऐसे स्थान होते हैं जहां हमने मरीजों के दस्तावेज़ सहेजे हैं। ऐसे दस्तावेजों के उदाहरण मरीजों के चार्ट, एक्स-रे और चालान के स्कैन हो सकते हैं। बेशक हम इन दस्तावेज़ों को सीधे डेटाबेस में नहीं सहेजेंगे। यह दस्तावेज़ प्रबंधन प्रणाली का एक कठोर सरलीकरण है। document तालिका हैं (सभी अनिवार्य हैं):

• description - एक संक्षिप्त दस्तावेज़ विवरण है
• location - सटीक दस्तावेज़ स्थान है
• patient_id - patient टेबल

tooth तालिका एक साधारण शब्दकोश है जिसका उपयोग बाद में तब किया जाता है जब दंत चिकित्सक यह निर्दिष्ट करता है कि कौन सा दांत समस्या थी। इस तालिका में सभी विशेषताएँ आवश्यक हैं। वे हैं:

• is_baby_tooth - एक बूलियन मान है जो केवल यह दर्शाता है कि दांत शिशु का दांत है या नहीं। बेशक, हमारे पास दांतों के लिए डुप्लिकेट मान होंगे जो दोनों हो सकते हैं। यह महत्वपूर्ण है क्योंकि दांत के प्रकार के अनुसार एक प्रक्रिया भिन्न हो सकती है।
• tooth - दांत के काम करने के लिए इस्तेमाल किया जाने वाला विवरण है - आम तौर पर, वह मान स्क्रीन पर दिखाया जाएगा।

problem_catalog तालिका एक और सरल शब्दकोश है। इसमें सामान्य रूप से दांतों या मुंह में पाई जाने वाली सभी संभावित समस्याओं की एक सूची है। इस कैटलॉग के संभावित मूल्यों के उदाहरण हैं:"दांत क्षय", "दांत क्षरण", "मसूड़े की सूजन", "मुंह के घाव" या "अनाकर्षक मुस्कान"। केवल problem_name विशेषता अनिवार्य है।

problem_detected तालिका विज़िट, दांत और समस्या कैटलॉग डेटा को treatment टेबल। इसमें tooth , problem_catalog और visit टेबल। tooth_id . को छोड़कर सभी विशेषताएँ अनिवार्य हैं . इस अपवाद का कारण यह है कि कुछ समस्याएं केवल एक दांत को संदर्भित नहीं करती हैं (उदाहरण के लिए मसूड़े की सूजन मसूड़ों को संदर्भित करती है)। ये तीनों विशेषताएँ मिलकर एक वैकल्पिक कुंजी (UNIQUE) बनाती हैं। अन्य दो विशेषताएँ हैं:

• suggested_treatment_id treatment तालिका (दंत चिकित्सक द्वारा सुझाया गया उपचार)। जब सब कुछ ठीक हो और हमें किसी उपचार की आवश्यकता न हो, तो यह NULL मान हो सकता है।
• selected_treatment_id treatment टेबल। इसमें उपचार दंत चिकित्सक और रोगी के उपयोग के लिए सहमत होने के बारे में डेटा शामिल है। यह शून्य हो सकता है, शायद इसलिए कि रोगी को सुझाए गए उपचार और अन्य संभावनाओं के बारे में सोचने के लिए समय चाहिए।

ध्यान दें कि विशेषताएँ suggested_treatment_id और selected_treatment_id दोनों का संदर्भ treatment टेबल। हम ऐसा इसलिए कर सकते हैं क्योंकि हमें केवल दो मूल्यों को स्टोर करने की आवश्यकता है। बेशक, अगर हम पहले से नहीं जानते हैं कि हम कितने मूल्यों को स्टोर करना चाहते हैं तो हमें यहां कई-से-अनेक संबंध का उपयोग करना चाहिए।

step तालिका एक सरल शब्दकोश है जिसमें सभी उपचारों में सभी संभावित चरण शामिल हैं। तालिका में विशेषताएँ (सभी अनिवार्य हैं) हैं:

• step_name - ऑन-स्क्रीन इस्तेमाल किया जाने वाला एक छोटा चरण नाम है
• description – इस चरण के दौरान की गई कार्रवाइयों का विवरण है

treatment तालिका वास्तव में सभी उपचारों का एक शब्दकोश है जो दंत चिकित्सा कार्यालय प्रदान करता है। चूंकि अधिकांश उपचारों में आमतौर पर कई चरण होते हैं, हमें पता होना चाहिए कि कौन सा चरण अंतिम है। तालिका में सभी विशेषताएँ आवश्यक हैं:

• treatment_name - प्रणाली के भीतर उपचार का नाम है
• description - एक संक्षिप्त उपचार विवरण है
• final_step_id - step टेबल। हम इस जानकारी का उपयोग यह पता लगाने के लिए कर सकते हैं कि क्या उपचार समाप्त हो गया है और स्वचालित कार्रवाई शुरू कर सकते हैं, या हम केवल उपयोगकर्ता को वह जानकारी दिखा सकते हैं और उसे अगली कार्रवाई चुनने दे सकते हैं।

treatment_steps तालिका कई-से-अनेक संबंध है जो उपचार के साथ चरणों को जोड़ता है। तालिका में अनिवार्य विशेषताएं हैं:

• treatment_id - treatment टेबल
• step_id - step टेबल
• step_order - एक संख्या है जो उपचार में चरणों के क्रम को परिभाषित करती है

इस तालिका में दो वैकल्पिक कुंजियाँ (UNIQUE) परिभाषित हैं:

• जोड़ी (treatment_id &step_id ) - यह चरण केवल एक बार उपचार के लिए नियत किया जा सकता है
• जोड़ी (treatment_id &step_order ) - उपचार में एक ही क्रम संख्या वाले दो चरण नहीं हो सकते हैं

visit_steps तालिका उन सभी चरणों की सूची है जो वास्तव में उस यात्रा के बाद किए गए थे। हम उन्हें अलग-अलग तालिकाओं में क्यों संग्रहीत करना चाहते हैं, इसके दो कारण हैं:

1. हो सकता है कि हमने एक उपचार चुना हो, लेकिन हमें इसके लिए परिभाषित सभी चरणों की आवश्यकता नहीं है, और
2. इस तरह, हम चरण के निष्पादित होने के वास्तविक समय को सहेज लेंगे।

तालिका में विशेषताएँ (problem_detected_id . को छोड़कर सभी अनिवार्य हैं और notes ) इस प्रकार हैं:

• visit_id - visit टेबल
• treatment_steps_id - treatment_steps टेबल
• problem_detected_id - problem_detected टेबल। यह संबंध हमें इस बात की जानकारी देता है कि किस समस्या ने उस कार्रवाई को शुरू किया। यह शून्य हो सकता है जब दंत चिकित्सक कुछ ऐसी कार्रवाई करने का निर्णय लेता है जो किसी भी ज्ञात समस्या से संबंधित नहीं है।
• step_time - वह तारीख और/या समय है जब चरण वास्तव में निष्पादित किया गया था
• notes - यदि आवश्यक हो तो उस चरण के लिए नोट्स हैं

visit_status तालिका एक साधारण शब्दकोश है जिसका उपयोग विज़िट की सभी संभावित स्थितियों को संग्रहीत करने के लिए किया जाता है। हम "पहले कभी कार्यालय की यात्रा", "पहली यात्रा", "प्रगति में उपचार", "उपचार सफलतापूर्वक समाप्त" जैसी स्थितियों का उपयोग कर सकते हैं। इसमें केवल एक विशेषता है, status_name , जो अनिवार्य है।

visit_status_history तालिका का उपयोग विज़िट की गई स्थितियों के बारे में डेटा संग्रहीत करने के लिए किया जाता है। विचार यह है कि हम कुछ क्रियाओं के पूरा होने के बाद मैन्युअल रूप से स्थिति जोड़ते हैं (उदाहरण के लिए इतिहास के बाद, कुछ उपचार के कुछ चरणों को पूरा करने के बाद)। विशेषताएँ, जिनमें से सभी आवश्यक हैं, का पालन करें:

• status_time - वह तारीख/समय है जब स्थिति डाली गई थी
• visit_status_id - visit_status टेबल
• visit_id - visit टेबल

दंत डेटाबेस मॉडल में संभावित सुधार

हमारा मॉडल अच्छी शुरुआत के लिए तैयार है, लेकिन इसमें सुधार किया जा सकता है। उदाहरण के लिए, इसमें निम्नलिखित आइटम शामिल नहीं हैं:

• भुगतान के तरीके और चालान
• शेड्यूलिंग मीटिंग्स (हालांकि यह visit_steps भविष्य की घटनाओं के लिए तालिका)
• दस्तावेज़ प्रबंधन

फिर भी, यह आपको अपने दंत कार्यालय और इसकी प्रक्रियाओं के बारे में अलग तरह से सोचने पर मजबूर करता है, है ना?