Database
 sql >> डेटाबेस >  >> RDS >> Database

बिक्री रिकॉर्ड करने के लिए एक डेटाबेस मॉडलिंग। भाग 1

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

हर कोई कुछ न कुछ बेचकर जीता है।

रॉबर्ट लुइस स्टीवेन्सन

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

हम एक बहुत ही सरल उदाहरण के साथ शुरुआत करेंगे:एक कॉफी शॉप . में बिक्री के लिए एक डेटाबेस मॉडल . बाद के लेखों में, हम अन्य शाखाओं में उत्पाद बेचने के लिए मॉडल का विस्तार करेंगे।

बिक्री मॉडल

इस लेख में हम मॉडल के केवल एक हिस्से का विश्लेषण करेंगे जिसमें बिक्री डेटा शामिल है और अन्य भाग गायब हैं।

हमारे पास अभी भी अनुपलब्ध तालिकाओं से संबंध हैं और हम मॉडल को ब्लैक-बॉक्स के रूप में देखेंगे, यह मानते हुए कि तालिका sale :

  • user_has_role_id user_has_role (जैसा कि "समय घटक जोड़ा गया" अनुभाग में मेरे पिछले लेख में प्रस्तुत किया गया है) और बिक्री रिकॉर्ड बनाने वाले उपयोगकर्ता के बारे में जानकारी संग्रहीत करता है



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

टेबल्स

आइए तालिका परिभाषा पर एक नज़र डालें और विशेषताओं के उद्देश्य और उपयोग की व्याख्या करें।

मॉडल में सबसे महत्वपूर्ण तालिका है product . इसका उपयोग उन उत्पादों के बारे में विवरण संग्रहीत करने के लिए किया जाता है जो हम अपने ग्राहकों को प्रदान करेंगे। उत्पाद आमतौर पर एक ग्राहक को वितरित किए जाते हैं और एक बार के लिए भुगतान किया जाता है, आमतौर पर डिलीवरी के समय। साथ ही, उत्पाद आमतौर पर कार, फोन, चीनी के पैकेज या कॉफी के कप जैसी भौतिक वस्तुएं होते हैं।

हम अगले लेखों में गैर-भौतिक चीजों (सेवाओं) को बेचने के बारे में बात करेंगे।

product टेबल हैं:

  • name - सिस्टम में उत्पाद का नाम
  • price_per_unit - प्रति यूनिट उत्पाद की लागत (जैसे, 1 कप कॉफी की कीमत 1.8 यूरो, 1 कार की कीमत 17,500 यूरो, 1 किलो चावल की कीमत 2 यूरो)
  • basic_unit - आधार इकाई जब हम कोई उत्पाद बेच रहे होते हैं (जैसे, टुकड़ा, किलो, लीटर)
  • tax_percentage - price_per_unit का प्रतिशत कर के रूप में लिया जाना है। हमें यह मान लेना चाहिए कि सभी उत्पादों के लिए कर प्रतिशत समान नहीं होगा
  • limited - यदि हमारे पास स्टॉक पर सीमित मात्रा है और अन्यथा गलत है तो यह फ़ील्ड सही पर सेट है (उदाहरण के लिए, हम किसी वितरक से अपने स्टोर के लिए जितनी भी मात्रा की आवश्यकता है, ऑर्डर कर सकते हैं)
  • in_stock – अगर सीमित =सही है तो यह विशेषता दर्शाती है कि हमारे पास बेचने के लिए कितने उपलब्ध हैं
  • active_for_sale - अगर यह विशेषता गलत है, तो हम वर्तमान में उस उत्पाद को बिक्री के लिए नहीं दे रहे हैं, अन्यथा हम इसे ग्राहकों को दे सकते हैं

हम निम्नलिखित प्रश्नों के साथ उन उत्पादों की सूची प्राप्त कर सकते हैं जिन्हें हम ग्राहकों को दे सकते हैं:

SELECT product.id, product.price_per_unit, 
       product.basic_unit, product.limited, product.in_stock
FROM product
WHERE product.active_for_sale = True
AND (product.limited = False OR
      (product.limited = True and product.in_stock > 0))

तालिका sale_status एक साधारण शब्दकोश है जिसमें सभी स्थितियां शामिल हैं जो एक बिक्री प्रणाली में हो सकती हैं (उदाहरण के लिए, "रसीद जारी", "रसीद भुगतान")।

तालिका sale इस मॉडल में दूसरी सबसे महत्वपूर्ण तालिका है। अब तक, इस तालिका का उन ग्राहकों से कोई संबंध नहीं है, जिन्हें हमने उत्पाद बेचे थे, क्योंकि हमारे कॉफी शॉप उदाहरण में, हमें ऐसी जानकारी जानने की आवश्यकता नहीं है। भाग 2 में, ऐसे मामलों को कवर करने के लिए मॉडल का विस्तार किया जाएगा।

तालिका में विशेषताएँ और उनके अर्थ हैं:

  • time_created - वह समय जब सिस्टम में एक बिक्री रिकॉर्ड बनाया गया था (उदाहरण के लिए, स्वचालित समय जब रिकॉर्ड बनाया गया था जब हमने अपनी कॉफी शॉप में कॉफी के लिए बिक्री उत्पन्न की थी या यदि हम इसे चाहते हैं तो मैन्युअल रूप से जोड़ा गया समय)
  • time_paid - आम तौर पर हम उम्मीद कर सकते हैं कि कुछ बिक्री का भुगतान कुछ दिनों के भीतर या निर्माण के एक महीने बाद भी किया जाएगा (उदाहरण के लिए, यदि हम सॉफ़्टवेयर वितरित करते हैं और रसीद बनाते हैं तो हम कुछ देशों में भुगतान प्राप्त करने के लिए 90 दिनों तक प्रतीक्षा कर सकते हैं, अगर सब कुछ ठीक हो जाता है कानून)
  • sale_amount - मूल राशि जो ग्राहक से वसूल की जानी है
  • sale_amount_paid - वह राशि जो ग्राहक ने वास्तव में भुगतान की थी। यह शून्य हो सकता है क्योंकि फिलहाल हम एक रसीद बनाते हैं, हमारे पास हमेशा यह जानकारी नहीं होती है
  • tax_amount - उस रसीद पर आइटम के लिए सभी कर राशियों का योग
  • sale_status_id - sale_status टेबल
  • user_has_role_id - उपयोगकर्ता का संदर्भ और उस समय उसकी भूमिका जब उसने सिस्टम में रसीद दर्ज की थी

हम इस तरह की क्वेरी के साथ जारी और भुगतान की गई राशि (time_created के अनुसार) समय के भीतर प्राप्त कर सकते हैं:

SELECT SUM(sale.sale_amount) AS amount_issued,
       SUM(sale.sale_amount_paid) AS amount_paid 
FROM sale
WHERE sale.time_created >= @start_time 
AND sale.time_created <= @end_time;

एक निश्चित अवधि के भीतर भुगतान की गई सटीक राशि प्राप्त करने के लिए हमें इस तरह की एक क्वेरी का उपयोग करना चाहिए:

SELECT SUM(sale.sale_amount_paid) AS amount_paid 
FROM sale
WHERE sale.time_paid >= @start_time 
AND sale.time_paid <= @end_time;

नीचे दी गई क्वेरी जारी की गई और भुगतान की गई राशि की गणना एक निश्चित अवधि के भीतर करेगी और जारी करने की तारीख और भुगतान की तारीख की अलग-अलग जांच की जाएगी:

SELECT 
SUM(CASE WHEN sale.time_created >= @start_time 
    AND sale.time_created <= @end_time 
    THEN sale.sale_amount END) AS amount_issued,
SUM(CASE WHEN sale.time_paid >= @start_time 
    AND sale.time_paid <= @end_time 
    THEN sale.sale_amount_paid END) AS amount_paid 
FROM sale

सभी उदाहरणों में @start_time और @end_time वे वेरिएबल्स हैं जिनमें अवधि का प्रारंभ समय और समाप्ति समय होता है जिसके लिए हम जारी किए गए और भुगतान किए गए एसयूएम की जांच करना चाहते हैं।

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

गुण और उनके अर्थ हैं:

  • quantity_sold - बेचे गए उत्पाद की मात्रा और उस बिक्री/रसीद पर शुल्क लिया जाता है (उदाहरण के लिए, 3 कॉफ़ी)
  • price_per_unit - product.price_per_unit . के समान मान उस समय जब बिक्री बनाई गई थी। हमें इसे सहेजना होगा क्योंकि price_per_unit product समय के साथ तालिका बदल सकती है
  • price - quantity_sold . का उत्पाद और price_per_unit; एक छोटा सा अतिरेक जो हमें प्रश्नों में इस गणना से बचने में मदद करता है। आम तौर पर, एक ही बिक्री से संबंधित सभी आइटम की कीमतों का योग sale.sale_amount के बराबर होना चाहिए
  • tax_amount - रसीद पर उस वस्तु के लिए कर राशि
  • sale_id - बिक्री की आईडी जिससे यह आइटम संबंधित है
  • product_id – इस आइटम से संबंधित उत्पाद आईडी

अब हम आसानी से एक साधारण रिपोर्ट बना सकते हैं कि हमने कितने उत्पाद/सेवाएं इस अवधि में और किस कीमत पर बेचीं।

SELECT product.name, SUM(sale_item.quantity_sold) AS quantity, 
       SUM(sale_item.price) AS price
FROM sale, sale_item, product
WHERE sale.id = sale_item.sale_id
AND sale_item.product_id = product.id
AND sale.time_created >= @start_time 
AND sale.time_created <= @end_time
GROUP BY product.id


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL में 3 टेबल्स में शामिल हों

  2. SQL कमांड को कैसे वर्गीकृत किया जाता है | यूबीआईक्यू

  3. SQL डिज़ाइन और प्रश्नों को आज़माने के लिए ऑनलाइन उपकरण

  4. सिग्नल प्रोसेसिंग डेटा मॉडल के साथ सिग्नल ट्रैक करें

  5. ट्रेस फ्लैग 2389 और नया कार्डिनैलिटी अनुमानक