एक रियल एस्टेट एजेंसी डेटा मॉडल

स्थान के अलावा, एक सफल रियल एस्टेट व्यवसाय चलाने के लिए क्या आवश्यक है? रियल एस्टेट एजेंसियों को संगठित रहने में मदद करने के लिए हम डेटा मॉडल की जांच करते हैं।

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

जाहिर है, संपत्तियों पर नज़र रखना एक रियल एस्टेट व्यवसाय चलाने का एक महत्वपूर्ण हिस्सा है। वहीं तारीखों का भी उतना ही महत्व है। (उदाहरण के लिए एक किराये का अपार्टमेंट कब उपलब्ध होगा? संपत्ति का एक टुकड़ा बाजार में कब जा रहा है?) इस लेख में, हम एक डेटा मॉडल पर एक नज़र डालेंगे जो रियल एस्टेट कंपनियों को संगठित रहने में मदद कर सकता है।

अचल संपत्ति संबंधी अक्सर पूछे जाने वाले प्रश्न

इससे पहले कि हम मॉडल और उसके अपेक्षित डेटा का वर्णन करना शुरू करें, हम पहले रियल एस्टेट व्यवसाय से संबंधित कुछ सवालों के जवाब देंगे। रियल एस्टेट की कई शर्तें हैं और इसके शब्दजाल और सिद्धांतों की पूरी व्याख्या इस लेख के दायरे से काफी दूर है, इसलिए हम यहां केवल सबसे सामान्य और बुनियादी सवालों के जवाब देंगे।

क्या संपत्ति या संपत्ति माना जा सकता है?

जब हम अचल संपत्ति के बारे में सोचते हैं, तो हमें जो पहली छवि मिलती है वह अक्सर एक घर या किसी अन्य आवास की होती है। रियल एस्टेट इससे कहीं ज्यादा है। भवन, कार्यालय, भूमि, खनिज संसाधन और वाहिनी भी इसी श्रेणी में आते हैं। इस लेख के प्रयोजन के लिए, मैं "अचल" सब कुछ अचल संपत्ति के रूप में मानूंगा। ऐसा कहने के बाद, हम मुख्य रूप से अपार्टमेंट इमारतों और घरों पर ध्यान केंद्रित करेंगे।
संपत्ति या संपत्ति कहां स्थित है?

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

हमारे मॉडल में, हमें उन सभी सम्पदाओं (अर्थात वास्तविक संपत्तियों) और ग्राहकों को संग्रहीत करने की आवश्यकता है जिनके साथ हम काम करते हैं। रिपोर्ट बनाने और अपने व्यवसाय को बेहतर बनाने के लिए भी हमें इस जानकारी की आवश्यकता है।

हम उम्मीद कर सकते हैं कि हम ग्राहकों के साथ अक्सर संवाद करेंगे, इसलिए हमें उनके सभी संपर्क विवरण संग्रहीत करने होंगे। हम यह भी जानना चाहेंगे कि किस कर्मचारी ने क्लाइंट से संपर्क किया और बातचीत के दौरान क्लाइंट ने क्या दिलचस्पी दिखाई।

संपत्तियों के लिए, हमें अपनी उंगलियों पर उनके विवरण और वर्तमान स्थिति की आवश्यकता है ताकि हम संभावित ग्राहकों की पूछताछ का तुरंत उत्तर दे सकें।

हम अपने संपर्क इतिहास और ग्राहकों या संपत्तियों से संबंधित किसी भी अनुबंध को भी संग्रहीत करेंगे।
तिथियां कितनी महत्वपूर्ण हैं?

तिथियां हमेशा महत्वपूर्ण होती हैं, लेकिन मैं इस बात पर जोर देना चाहता हूं कि वे अचल संपत्ति में विशेष रूप से महत्वपूर्ण हैं। हमें यह जानने की जरूरत है कि हमारी किराये की संपत्तियों में से कितने समय पर कब्जा कर लिया गया है ताकि जैसे ही यह उपलब्ध हो, हम इसे फिर से किराए पर ले सकें। जब दो ग्राहक एक ही संपत्ति किराए पर लेते हैं तो कोई अतिव्यापी नहीं हो सकता है। यदि कोई संभावित ग्राहक भविष्य की किसी विशिष्ट तिथि पर किराए पर लेने की इच्छा व्यक्त करता है, तो हमें उस जानकारी को संग्रहीत करना चाहिए और उस तिथि के निकट आने पर एक अनुस्मारक प्राप्त करना चाहिए।
हमारा आवेदन कैसा दिखना चाहिए?

इस उद्देश्य के लिए, एक वेब एप्लिकेशन सबसे अच्छा समाधान है। अधिकांश अचल संपत्ति का काम कार्यालय-आधारित है, लेकिन बिक्री एजेंट जहां कहीं भी हों, नए डेटा डालने में सक्षम होना चाहिए। हमारे ऐप में सबसे महत्वपूर्ण कार्यक्षमता एक तेज़ खोज है जो क्लाइंट, प्रॉपर्टी और प्रॉपर्टी की स्थिति ढूंढ सकती है।

डेटा मॉडल

हमारे रियल एस्टेट डेटा मॉडल में तीन मुख्य विषय क्षेत्र शामिल हैं:

Estates and locations
Clients and contacts
Contracts and transactions

एक टेबल है, employee , जो किसी भी विषय क्षेत्र से बाहर है।

कृपया ध्यान दें कि employee और estate Clients and contacts में टेबल विषय क्षेत्र और client Contracts and transactions में तालिका विषय क्षेत्र केवल प्रतियाँ हैं जिनका उपयोग मॉडल को सरल बनाने के लिए किया जाता है।

हम employee तालिका पहले, Estates and locations के साथ जारी रखें , Clients and contacts पर जाएं , और फिर Contracts and transactions . के साथ समाप्त करें ।

कर्मचारी तालिका

हम employee टेबल। यह आसान है:यह केवल first_name . को संग्रहीत करता है और last_name प्रत्येक कर्मचारी की। हम कर्मचारी के टैक्स आईडी नंबर, उनकी जन्म तिथि, पता, नौकरी की भूमिका आदि जैसे अन्य विवरण जोड़ सकते हैं। हालांकि, इस मॉडल में हम कर्मचारियों पर ध्यान केंद्रित नहीं करेंगे, इसलिए हमें केवल कर्मचारियों को जोड़ने का एक तरीका चाहिए। क्रियाएँ (जैसे किसी कार्य या अनुबंध को सौंपा जाना)। यह तालिका हमें यह भी रिकॉर्ड करने देगी कि प्रत्येक ग्राहक संपर्क में किस कर्मचारी ने भाग लिया।

अनुभाग 1:संपदा और स्थान

Estates and locations विषय क्षेत्र में छह टेबल हैं जो उन सभी संपत्तियों (गुणों) का वर्णन करती हैं जिनके साथ हम काम करते हैं, उनके स्थान और उनकी वर्तमान स्थिति।

इस विषय क्षेत्र में केंद्रीय तालिका estate टेबल। इसमें उन सभी सम्पदाओं की एक सूची है, जिनके साथ हम काम कर रहे हैं, थे या होंगे। इसमें सम्पदा शामिल है जिसके लिए हम दो ग्राहकों के बीच मध्यस्थता करते हैं, जो हमारे पास हैं, जिन्हें हमने ग्राहकों को बेचा या किराए पर दिया है, और कोई भी जिसे हमने ग्राहकों से पट्टे या खरीदा है। यह उन सम्पदाओं का भी रिकॉर्ड रखता है जिनके साथ हम व्यापार करने की योजना बनाते हैं (या योजना बनाई थी)।

चूंकि हम इस लेख में मुख्य रूप से अपार्टमेंट और घरों पर ध्यान केंद्रित कर रहे हैं, इसलिए इस तालिका की विशेषताएँ ज्यादातर उनसे संबंधित हैं। यदि हम अन्य प्रकार की वास्तविक संपत्ति का वर्णन करना चाहते हैं, तो हम अतिरिक्त अशक्त वर्णनात्मक विशेषताएँ जोड़ सकते हैं। हम उन मानों को estate_description . में भी आसानी से दर्ज कर सकते हैं गुण। estate टेबल हैं:

estate_name - संपत्ति का नाम। यह एक संपत्ति ("स्टोकर हाउस") या एक प्रसिद्ध सार्वजनिक नाम ("ब्रान कैसल") के लिए हमारा आंतरिक नाम हो सकता है।
city_id - उस शहर की आईडी जहां संपत्ति स्थित है।
estate_type_id - estate_type शब्दकोश।
floor_space और balconies_space - अपार्टमेंट के फर्श और बालकनियों का आकार (वर्ग मीटर में)।
number_of_balconies , number_of_bedrooms , number_of_garages और number_of_parking_spaces - प्रत्येक श्रेणी के लिए पूर्णांक मान। स्व-व्याख्यात्मक।
pets_allowed - एक बूलियन मान यह दर्शाता है कि पालतू जानवरों की अनुमति है या नहीं। यह ज्यादातर किराये की संपत्तियों के लिए उपयोग किया जाता है।
estate_description - एक संपत्ति का विस्तृत विवरण। यह वह जगह है जहां हम कोई अतिरिक्त जानकारी संग्रहीत करते हैं, उदा। संपत्ति इतिहास।
estate_status_id - यदि कोई संपत्ति वर्तमान में उपलब्ध है या नहीं। हम इस फ़ील्ड का उपयोग अपने खोज फ़ंक्शन में करेंगे।

हमने पहले ही दो शब्दकोशों का उल्लेख किया है कि estate तालिका का अर्थ है, estate_type और estate_status . इन दोनों शब्दकोशों में केवल एक आईडी और एक अद्वितीय नाम विशेषता है।

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

हम न केवल विवरण (estate . द्वारा, प्रत्येक एस्टेट के स्थान को परिभाषित करेंगे . estate_description विशेषता), लेकिन इसके देश और शहर द्वारा भी। इस उद्देश्य के लिए, हम दो शब्दकोश तालिकाओं का उपयोग करेंगे:country और city . प्रत्येक देश को विशिष्ट रूप से country_name . द्वारा परिभाषित किया जाता है , जो तालिका में संग्रहीत एकमात्र विशेषता (आईडी के अलावा) होगी। दूसरी ओर, प्रत्येक शहर का एक नाम और एक देश होता है। कुछ शहरों का एक ही नाम हो सकता है, लेकिन हम मान लेंगे कि प्रत्येक शहर का नाम अपने देश के लिए अद्वितीय है - केवल एक वियना, ऑस्ट्रिया या जिनेवा, स्विट्ज़रलैंड। हालांकि, अगर हम डुप्लीकेट से बचाव करना चाहते हैं, तो हम एक क्षेत्र विशेषता जोड़ सकते हैं। हालांकि, अभी के लिए, हम सब कुछ वैसे ही छोड़ देंगे। city_name - country_id जोड़ी city टेबल।

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

estate_id और employee_id - विदेशी कुंजियाँ जो क्रमशः संबंधित संपत्ति और क्लाइंट को संदर्भित करती हैं।
date_from और date_to - अंतराल जब कर्मचारी को उस संपत्ति को सौंपा गया था। ध्यान दें कि "date_to" NULL हो सकता है क्योंकि एक कर्मचारी अनिश्चित काल तक किसी संपत्ति की देखभाल कर सकता है। जब हम किसी कर्मचारी को किसी एस्टेट के लिए असाइन करते हैं, तो हमें अतिव्यापी दिनांक अंतरालों की जाँच करके यह सुनिश्चित करना चाहिए कि वे पहले से ही किसी अन्य एस्टेट को असाइन नहीं किए गए हैं। दूसरी ओर, हम एक ही समय में एक ही एस्टेट में कई कर्मचारियों को असाइन कर सकते हैं। यह वांछनीय होगा जब कर्मचारियों की अलग-अलग भूमिकाएँ हों, उदा। एक कर्मचारी क्लाइंट संचार का ख्याल रखता है, दूसरा कर्मचारी उस संपत्ति को दिखाता है, दूसरा बिक्री और कानूनी अनुबंधों आदि को संभालता है।

अनुभाग 2:ग्राहक और संपर्क

Clients and contacts विषय क्षेत्र में केवल दो टेबल होते हैं, client तालिका और contact टेबल। इस क्षेत्र में दिखाए गए दो अन्य टेबल, employee:Clients and contacts और estate:Clients and contacts सिर्फ प्रतियां हैं।

client तालिका में उन सभी ग्राहकों के रिकॉर्ड होते हैं जिनके साथ हमने कभी काम किया है, जिसमें वर्तमान और संभावित ग्राहक शामिल हैं। संभावित ग्राहक कौन है? यह कोई ऐसा व्यक्ति हो सकता है जिसने कहा हो कि वे भविष्य में हमसे कुछ संपत्ति बेचना, खरीदना या किराए पर लेना चाहते हैं। हमें भविष्य में उपयोग के लिए ऐसे ग्राहकों के संपर्क विवरण और संपत्तियों को संग्रहीत करने की आवश्यकता है। client टेबल हैं:

client_name - एक व्यक्ति के लिए, यह क्षेत्र उनका पहला और अंतिम नाम रखता है। यदि ग्राहक एक कानूनी इकाई है, तो उसके पास कंपनी या इकाई का नाम होता है।
client_address - क्लाइंट के स्थान का टेक्स्ट विवरण।
contact_person - हमारे संपर्क व्यक्ति का पहला और अंतिम नाम (और शायद एक नौकरी का शीर्षक यदि ग्राहक एक व्यवसाय है)।
phone , mobile और mail - ग्राहक का संपर्क विवरण।
client_details - उस ग्राहक से संबंधित अन्य सभी विवरण। ये एक असंरचित पाठ प्रारूप में संग्रहीत हैं।

इस तालिका में अंतिम पाँच विशेषताएँ अशक्त हैं क्योंकि वे महत्वपूर्ण नहीं हैं। हमें शायद कम से कम एक संपर्क व्यक्ति के लिए जानकारी संग्रहीत करने की आवश्यकता होगी, लेकिन हम पहले से नहीं जानते होंगे कि हमारा संपर्क कौन होगा।

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

client_id - शामिल क्लाइंट की आईडी।
employee_id - उस संपर्क उदाहरण में शामिल कर्मचारी की आईडी। यह NULL हो सकता है क्योंकि क्लाइंट किसी व्यक्तिगत कर्मचारी से संपर्क नहीं कर सकता है - उदा। हो सकता है कि क्लाइंट ने कंपनी खाते में एक ईमेल भेजा हो। फिर भी, ज्यादातर मामलों में हम उम्मीद कर सकते हैं कि हमें पता चल जाएगा कि किस कर्मचारी ने बातचीत को संभाला है।
estate_id - संबंधित संपत्ति की आईडी। यह तब उपयोगी होता है जब ग्राहक एक निश्चित संपत्ति के लिए पूछता है या यदि ग्राहक हमारे सिस्टम में पहले से मौजूद किसी चीज को बेचना या पट्टे पर देना चाहता है।
contact_time - वह समय जब संपर्क हुआ।
contact_details - कोई भी असंरचित नोट जिसे हम उस संपर्क के बारे में सहेजना चाहते हैं। हम कुछ ऐसा लिख सकते हैं "ग्राहक ने <इस> पड़ोस में एक घर खरीदने की इच्छा व्यक्त की।"

धारा 3:अनुबंध और लेनदेन

हमारे मॉडल में अंतिम विषय क्षेत्र है Contracts and transactions . हम इसका उपयोग ग्राहकों के साथ सम्पदा को जोड़ने के लिए करेंगे।

इस खंड की केंद्रीय तालिका contract टेबल। यह वह जगह है जहां हम सभी अनुबंध विवरण संग्रहीत करेंगे और ग्राहकों और कर्मचारियों के साथ अनुबंधों को जोड़ेंगे। इस तालिका में विशेषताएँ हैं:

client_id - संबंधित अनुबंध पर हस्ताक्षर करने वाले ग्राहक की आईडी।
employee_id - हमारी कंपनी की ओर से अनुबंध पर हस्ताक्षर करने वाले कर्मचारी की आईडी।
contract_type_id - संदर्भ contract_type शब्दकोश और दर्शाता है कि क्या अनुबंध संपत्ति खरीदने, बेचने, पट्टे पर देने या किराए पर लेने से संबंधित है।
contract_details - टेक्स्ट प्रारूप में संगृहीत संपर्क का विस्तृत विवरण।
payment_frequency_id - payment_frequency शब्दकोश और इनवॉइस भेजे जाने के समय अंतराल को परिभाषित करता है।
number_of_invoices - चालान की संख्या जो जनरेट की जानी चाहिए। अगर कंपनी केवल एक बार भुगतान करती है, तो इस विशेषता में "1" का मान और संपूर्ण payment_amount जमा हो जाता है invoice_amount . के बराबर होगा ।
payment_amount - भुगतान की गई कुल राशि।
fee_percentage - वह प्रतिशत जो हम क्लाइंट से चार्ज करते हैं। उदाहरण के लिए, हम शुल्क के रूप में घर के बिक्री मूल्य का 5% चार्ज कर सकते हैं। इस कॉलम में मान contract_type . के समान होना चाहिए .fee_percentage इस अनुबंध के लिए विशेषता। fee_percentage विशेषता का उपयोग fee_amount की गणना के लिए किया जाएगा जब हम payment_amount . में कोई मान दर्ज करते हैं विशेषता।
fee_amount - इस अनुबंध के लिए हम ग्राहक से कुल शुल्क राशि वसूल करेंगे।
date_signed - वह तारीख जब अनुबंध पर हस्ताक्षर किए गए थे।
start_date - वह तारीख जब अनुबंध वैध हो जाता है (उदाहरण के लिए किराये या पट्टे के अनुबंध के लिए)।
end_date - अनुबंध समाप्त होने की तिथि। यदि हम किसी ऐसे अनुबंध पर हस्ताक्षर करते हैं जिसकी कोई समाप्ति तिथि नहीं है, तो यह NULL हो सकता है। हालांकि, ज्यादातर मामलों में हमें end_date पता चल जाएगा अग्रिम में।
transaction_id -संदर्भ transaction तालिका यदि अनुबंध दो ग्राहकों के बीच लेनदेन का एक हिस्सा है। इसमें NULL मान हो सकते हैं क्योंकि यदि अनुबंध सीधे हमारे और क्लाइंट के बीच है तो कोई संबंधित लेनदेन रिकॉर्ड नहीं होगा।

under_contract तालिका अनुबंध और सम्पदा से संबंधित है। प्राथमिक कुंजी विशेषता के अलावा id , इसमें केवल दो विदेशी कुंजियाँ हैं, estate_id और contract_id . यह विदेशी कुंजी जोड़ी तालिका की UNIQUE कुंजी भी बनाती है।

हम invoice टेबल। यदि ग्राहक पूरे अनुबंध के लिए एक ही भुगतान करता है, तो उस अनुबंध के लिए इस तालिका में केवल एक ही रिकॉर्ड होगा। यदि हम किसी ग्राहक को एक ही भुगतान करते हैं तो भी यही बात लागू होती है। यदि ग्राहक (या हमारी कंपनी) किश्तों में भुगतान करना चुनता है, तो contract में मान के समान ही रिकॉर्ड हैं। .number_of_invoices खेत। इस तालिका में विशेषताएँ हैं:

contract_id - संबंधित अनुबंध की आईडी।
invoice_number - चालान के लिए एक अद्वितीय आंतरिक पहचानकर्ता।
issued_by - चालान जारीकर्ता का एक पाठ विवरण। जब हम कोई चालान जारी करते हैं, तो हम अपनी कंपनी का विवरण यहां संग्रहीत करेंगे। यदि ग्राहक इसे जारी करता है, तो उनका विवरण यहां संग्रहीत किया जाएगा।
issued_to - issued_by . के विपरीत . यदि हम क्लाइंट से शुल्क लेते हैं, तो इस विशेषता में उनका विवरण होगा; यदि ग्राहक हमसे शुल्क लेता है, तो हमारे विवरण यहां संग्रहीत किए जाते हैं।
invoice_details - सभी चालान आइटम विवरण।
invoice_amount - इस चालान पर बकाया राशि।
date_created - वास्तविक तारीख जब हमारे सिस्टम में चालान बनाया गया था।
billing_date - वह तारीख जब चालान का भुगतान किया जाना चाहिए।
date_paid - वास्तविक तिथि जब चालान का भुगतान किया गया था। चालान का भुगतान होने तक यह NULL हो सकता है।

हम अनुबंधों का वर्णन करने के लिए दो और शब्दकोशों का उपयोग करेंगे, contract_type और payment_frequency . contract_type_name फ़ील्ड का उपयोग उस कार्रवाई को दर्शाने के लिए किया जाता है जो हम अनुबंध में कर रहे हैं:"मध्यस्थता (खरीदना)", "मध्यस्थता (बिक्री)", "मध्यस्थता (किराए पर)", "मध्यस्थता (पट्टे पर)", "खरीदना (एक ग्राहक से) ”, “बिक्री (एक ग्राहक को)”, “पट्टे पर (एक ग्राहक से)” और “किराए पर लेना (एक ग्राहक को)”। payment_frequency_name विशेषता बस यह बताती है कि हमारे या क्लाइंट द्वारा कितनी बार इनवॉइस जेनरेट किया जाएगा। यह "एक बार", "प्रति माह एक बार", "हर 2 महीने में एक बार" और "प्रति वर्ष एक बार" जैसे मूल्यों को संग्रहीत कर सकता है।

अगर हमारी कंपनी कुछ संपत्ति खरीदती है या पट्टे पर देती है, तो हम ग्राहक को भुगतान करेंगे। इसका मतलब है कि हम invoice . में शामिल होंगे .issued_to फ़ील्ड और हमें चालान का भुगतान करना होगा। अगर हम किसी संपत्ति को बेचते या किराए पर लेते हैं, तो ग्राहक हमें भुगतान करेगा और हम invoice में शामिल होंगे .issued_by फ़ील्ड.

यदि हम दो ग्राहकों के बीच किसी सौदे में मध्यस्थता करते हैं, तो हम अपनी सेवाओं के लिए शुल्क लेंगे। इस मामले में, हम दो अलग-अलग अनुबंधों पर हस्ताक्षर करेंगे, एक बेचने/किराए पर लेने वाले ग्राहक के साथ और दूसरा खरीदार/किराए पर लेने वाले ग्राहक के साथ। हम एक ही transaction_id . असाइन करके इन दोनों अनुबंधों को एक साथ जोड़ेंगे दोनों के लिए। transaction तालिका का उपयोग उन सौदों के रिकॉर्ड को संग्रहीत करने के लिए किया जाता है जिनकी हमने मध्यस्थता की है। इस तालिका में विशेषताएँ हैं:

transaction_id - प्रत्येक लेन-देन के लिए एक अद्वितीय आईडी।
transaction_type_id - transaction_type शब्दकोश।
client_offered - संदर्भ client तालिका और दर्शाती है कि कौन संपत्ति बेच रहा है या किराए पर ले रहा है।
client_requested - संदर्भ client तालिका और यह दर्शाता है कि संपत्ति कौन खरीद रहा है या पट्टे पर दे रहा है।
transaction_date - वह तारीख जब लेन-देन वास्तव में होगा।
transaction_details - उस लेन-देन से संबंधित सभी विवरण, एक असंरचित पाठ प्रारूप में संग्रहीत।

हमारे मॉडल में अंतिम तालिका transaction_type शब्दकोश। इस तालिका में संग्रहीत मूल्यों को प्रत्येक लेनदेन के अनुसार निर्दिष्ट किया जाता है:"खरीदना / बेचना" या "किराए पर लेना / पट्टे पर देना"।

एक रियल एस्टेट कंपनी चलाना बहुत जटिल, मांग और जोखिम भरा भी है। सब कुछ सुचारू रूप से चलने के लिए, संगठन के एक बड़े सौदे की जरूरत है। मुझे उम्मीद है कि इस डेटा मॉडल ने आपको इस क्षेत्र की जटिलता को समझने में मदद की है।

हमेशा की तरह, इस मॉडल को बेहतर बनाने के कई तरीके हैं। बेझिझक अपने सुझाव और टिप्पणियां साझा करें।