सामान्य से अधिक सूक्ष्म रूप से रिपोर्ट करना - Microsoft Access

आमतौर पर, जब हम रिपोर्टिंग करते हैं, तो हम आमतौर पर इसे उच्च ग्रैन्युलैरिटी पर करते हैं। उदाहरण के लिए, ग्राहक आमतौर पर बिक्री की मासिक रिपोर्ट चाहते हैं। डेटाबेस व्यक्तिगत बिक्री को एक रिकॉर्ड के रूप में संग्रहीत करेगा, इसलिए प्रत्येक महीने के आंकड़ों को संक्षेप में प्रस्तुत करने में कोई समस्या नहीं है। साल के साथ ठीक वैसा ही, या यहां तक ​​कि एक उप-श्रेणी से श्रेणी में जा रहा है।

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

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

मान लीजिए कि एक उत्पाद के लिए हमने 3 खरीदारी की हैं:
Date | Qty | Per-Cost
9/03 | 3 | $45
9/08 | 6 | $40
9/09 | 8 | $50
फिर हम बाद में उन उत्पादों को अलग-अलग अवसरों पर अलग-अलग कीमतों पर बेचते हैं:
Date | Qty | Per-Price
9/05 | 2 | $60
9/07 | 1 | $55
9/10 | 4 | $50
9/12 | 3 | $60
9/15 | 3 | $65
9/19 | 4 | $55
ध्यान दें कि विवरण लेन-देन के स्तर पर है — हम प्रत्येक खरीदारी और प्रत्येक आदेश के लिए एक एकल रिकॉर्ड बनाते हैं। यह बहुत सामान्य है और तार्किक समझ में आता है - हमें केवल एक विशेष लेनदेन के लिए एक निर्दिष्ट मूल्य पर बेचे गए उत्पादों की मात्रा दर्ज करने की आवश्यकता है।

ठीक है, आपके द्वारा अस्वीकृत लेखांकन सामग्री कहां है?

रिपोर्ट के लिए, हमें उत्पाद की प्रत्येक इकाई पर किए गए राजस्व की गणना करनी चाहिए। वे मुझसे कहते हैं कि उन्हें उत्पाद को FIFO तरीके से संसाधित करना चाहिए ... यानी, उत्पाद की पहली इकाई जो खरीदी गई थी, वह उत्पाद की पहली इकाई होनी चाहिए। फिर उत्पाद की उस इकाई पर हमारे द्वारा किए गए मार्जिन की गणना करने के लिए, हमें उत्पाद की उस विशेष इकाई की लागत को देखना चाहिए, फिर उस कीमत से घटाना चाहिए जिसके लिए इसका आदेश दिया गया था।

सकल मार्जिन =उत्पाद का राजस्व - उत्पाद की लागत

कुछ भी नहीं बिखर रहा है, लेकिन रुको, खरीद और आदेशों को देखो! हमने 3 अलग-अलग लागत बिंदुओं के साथ केवल 3 खरीदारी की थी, फिर हमारे पास 3 अलग-अलग मूल्य बिंदुओं के साथ 6 ऑर्डर थे। तब कौन सा लागत बिंदु किस मूल्य बिंदु पर जाता है?

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

इसे तोड़ना

मान लीजिए कि लेखांकन उद्देश्य के लिए, हम उत्पाद की प्रत्येक व्यक्तिगत इकाई को क्रमबद्ध करने के लिए खरीद तिथि का उपयोग करेंगे। इसे इस तरह सामने आना चाहिए:
Line # | Purch Date | Order Date | Per-Cost | Per-Price
1 | 9/03 | 9/05 | $45 | $60
2 | 9/03 | 9/05 | $45 | $60
3 | 9/03 | 9/07 | $45 | $55
4 | 9/08 | 9/10 | $40 | $50
5 | 9/08 | 9/10 | $40 | $50
6 | 9/08 | 9/10 | $40 | $50
7 | 9/08 | 9/10 | $40 | $50
8 | 9/08 | 9/12 | $40 | $60
9 | 9/08 | 9/12 | $40 | $60
10 | 9/09 | 9/12 | $50 | $60
11 | 9/09 | 9/15 | $50 | $65
12 | 9/09 | 9/15 | $50 | $65
13 | 9/09 | 9/15 | $50 | $65
14 | 9/09 | 9/19 | $50 | $55
15 | 9/09 | 9/19 | $50 | $55
16 | 9/09 | 9/19 | $50 | $55
17 | 9/09 | 9/19 | $50 | $55
यदि आप विश्लेषण का अध्ययन करते हैं, तो आप देख सकते हैं कि ओवरलैप होते हैं जहां हम एक खरीद से कुछ उत्पाद का उपभोग करते हैं, जबकि दूसरी बार हमारे पास एक ऑर्डर होता है जो अलग-अलग खरीद से पूरा होता है।

जैसा कि पहले उल्लेख किया गया है, हमारे पास वास्तव में डेटाबेस में कहीं भी 17 पंक्तियाँ नहीं हैं। हमारे पास खरीद की केवल 3 पंक्तियाँ और ऑर्डर की 6 पंक्तियाँ हैं। हम दोनों में से किसी भी तालिका में से 17 पंक्तियाँ कैसे प्राप्त करते हैं?

और मिट्टी डालना

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

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

आइए पहले यह पता लगाने के मामले से निपटें कि हमें उत्पाद के कितने inits पर विचार करने की आवश्यकता है। यह स्पष्ट है कि ऑर्डर की गई इकाइयों की मात्रा या खरीदी गई इकाइयों की मात्रा का एक साधारण SUM () पर्याप्त नहीं होगा। नहीं, बल्कि, हमें खरीदे गए उत्पादों की मात्रा और ऑर्डर किए गए उत्पादों की मात्रा दोनों का SUM() होना चाहिए। फिर हम SUM () की तुलना करेंगे और उच्च वाले को चुनेंगे। हम इस क्वेरी से शुरू कर सकते हैं:
WITH ProductPurchaseCount AS (
SELECT
p.ProductID,
SUM(p.QtyBought) AS TotalPurchases
FROM dbo.tblProductPurchase AS p
GROUP BY p.ProductID
), ProductOrderCount AS (
SELECT
o.ProductID,
SUM(o.QtySold) AS TotalOrders
FROM dbo.tblProductOrder AS o
GROUP BY o.ProductID
)
SELECT
p.ProductID,
IIF(ISNULL(pc.TotalPurchases, 0) > ISNULL(oc.TotalOrders, 0), pc.TotalPurchases, oc.TotalOrders) AS ProductTransactionCount
FROM dbo.tblProduct AS p
LEFT JOIN ProductPurchaseCount AS pc
ON p.ProductID = pc.ProductID
LEFT JOIN ProductOrderCount AS oc
ON p.ProductID = oc.ProductID
WHERE NOT (pc.TotalPurchases IS NULL AND oc.TotalOrders IS NULL);
हम यहां क्या कर रहे हैं, हम 3 तार्किक चरणों में विभाजित हैं:

a) उत्पादों द्वारा खरीदी गई मात्रा का SUM() प्राप्त करें
b) उत्पादों द्वारा ऑर्डर की गई मात्रा का SUM() प्राप्त करें

क्योंकि हम नहीं जानते कि क्या हमारे पास कोई ऐसा उत्पाद हो सकता है जिसमें कुछ खरीदारी हो सकती है लेकिन कोई ऑर्डर नहीं है या ऐसा उत्पाद है जिसमें ऑर्डर दिए गए हैं लेकिन हमने कोई खरीदा नहीं है, हम 2 टेबल में शामिल नहीं हो सकते हैं। इस कारण से, हम उत्पाद तालिकाओं का उपयोग उन सभी ProductID के आधिकारिक स्रोत के रूप में करते हैं जिनके बारे में हम जानना चाहते हैं, जो हमें तीसरे चरण में लाता है:

ग) उनके उत्पादों के योगों का मिलान करें, यह निर्धारित करें कि क्या उत्पाद का कोई लेन-देन है (उदाहरण के लिए या तो खरीदारी या कभी किए गए आदेश) और यदि ऐसा है, तो जोड़ी की अधिक संख्या चुनें। यह किसी उत्पाद के कुल लेन-देन की हमारी गणना है।

लेकिन लेन-देन की गणना क्यों की जाती है?

यहां उद्देश्य यह पता लगाना है कि किसी उत्पाद की प्रत्येक व्यक्तिगत इकाई का पर्याप्त रूप से प्रतिनिधित्व करने के लिए हमें प्रति उत्पाद कितनी पंक्तियों की आवश्यकता है, जिसने या तो खरीद या ऑर्डर में भाग लिया था। हमारे पहले आदर्श उदाहरण में याद रखें, हमारे पास 3 खरीद और 6 ऑर्डर थे, जो दोनों खरीदे गए उत्पाद की कुल 17 इकाइयों के लिए संतुलित थे, फिर ऑर्डर किए गए। उस विशेष उत्पाद के लिए, हमें ऊपर दिए गए आंकड़े में डेटा उत्पन्न करने के लिए 17 पंक्ति बनाने में सक्षम होना होगा।

तो हम एक पंक्ति में 17 के एकल मान को 17 पंक्तियों में कैसे बदलते हैं? यहीं से टैली टेबल का जादू प्रवेश करता है।

यदि आपने टैली टेबल के बारे में नहीं सुना है, तो आपको अभी करना चाहिए। मैं दूसरों को आपको टैली टेबल के विषय में भरने देता हूँ; यहाँ, यहाँ और यहाँ। कहने के लिए पर्याप्त है, यह आपके SQL टूलकिट में एक दुर्जेय टूल है।

यह मानते हुए कि हम उपरोक्त क्वेरी को संशोधित करते हैं ताकि अंतिम भाग अब ProductTransactionCount नाम का एक CTE हो, हम इस प्रकार क्वेरी लिख सकते हैं:
<the 3 CTEs from previous exampe>
INSERT INTO tblProductTransactionStaging (
ProductID,
TransactionNumber
)
SELECT
c.ProductID,
t.Num AS TransactionNumber
FROM ProductTransactionCount AS c
INNER JOIN dbo.tblTally AS t
ON c.TransactionCount >= t.Num;
और पेस्टो! अब हमारे पास उतनी ही पंक्तियाँ हैं जितनी हमें आवश्यकता होगी - ठीक - प्रत्येक उत्पाद के लिए जिन्हें हमें लेखांकन करने की आवश्यकता है। ON क्लॉज में अभिव्यक्ति पर ध्यान दें - हम एक त्रिकोणीय जोड़ कर रहे हैं - हम सामान्य समानता ऑपरेटर का उपयोग नहीं कर रहे हैं क्योंकि हम पतली हवा से 17 पंक्तियों को उत्पन्न करना चाहते हैं। ध्यान दें कि क्रॉस जॉइन और WHERE क्लॉज के साथ एक ही चीज़ हासिल की जा सकती है। कौन सा बेहतर काम करता है यह जानने के लिए दोनों के साथ प्रयोग करें।

हमारे लेन-देन की गणना करना

तो हमारे पास हमारी अस्थायी तालिका पंक्तियों की सही संख्या है। अब, हमें खरीद और ऑर्डर के बारे में डेटा के साथ तालिका को पॉप्युलेट करने की आवश्यकता है। जैसा कि आपने चित्र में देखा, हमें क्रमशः खरीदी या ऑर्डर की तारीख तक खरीद और ऑर्डर करने में सक्षम होने की आवश्यकता है। और यहीं पर ROW_NUMBER() और टैली टेबल बचाव के लिए आती है।
SELECT
p.ProductID,
ROW_NUMBER() OVER (PARTITION BY p.ProductID ORDER BY p.PurchaseDate, p.PurchaseID) AS TransactionNumber,
p.PurchaseDate,
p.CostPer
FROM dbo.tblProductPurchase AS p
INNER JOIN dbo.tblTally AS t
ON p.QtyBought >= t.Num;
आपको आश्चर्य हो सकता है कि हमें ROW_NUMBER() की आवश्यकता क्यों है जब हम टैली के Num कॉलम का उपयोग कर सकते हैं। इसका उत्तर यह है कि यदि कई खरीद हैं, तो संख्या केवल उस खरीद की मात्रा जितनी अधिक होगी, लेकिन हमें 17 के रूप में उच्च जाने की आवश्यकता है - 3, 6 और 8 इकाइयों की कुल 3 अलग-अलग खरीद। इस प्रकार, हम ProductID द्वारा विभाजन करते हैं जबकि टैली की संख्या को खरीद आईडी द्वारा विभाजित कहा जा सकता है जो कि हम नहीं चाहते हैं।

यदि आप एसक्यूएल चलाते हैं, तो अब आपको एक अच्छा ब्रेकआउट मिलेगा, खरीदे गए उत्पाद की प्रत्येक इकाई के लिए एक पंक्ति लौटा दी जाएगी, खरीद तिथि के अनुसार आदेश दिया जाएगा। ध्यान दें कि हम उस मामले को संभालने के लिए परचेजआईडी द्वारा भी छाँटते हैं, जहाँ एक ही दिन में एक ही उत्पाद की कई खरीदारी हुई थी, इसलिए हमें यह सुनिश्चित करने के लिए किसी भी तरह से टाई को तोड़ना होगा कि प्रति-लागत के आंकड़ों की गणना लगातार की जाती है। फिर हम खरीदारी के साथ अस्थायी तालिका को अपडेट कर सकते हैं:
WITH PurchaseData AS (
<previous query>
)
MERGE INTO dbo.tblProductTransactionStaging AS t
USING PurchaseData AS p
ON t.ProductID = p.ProductID
AND t.TransactionNumber = p.TransactionNumber
WHEN MATCHED THEN UPDATE SET
t.PurchaseID = p.PurchaseID,
t.PurchaseDate = p.PurchaseDate,
t.CostPer = p.CostPer;
ऑर्डर का हिस्सा मूल रूप से एक ही है - बस "खरीद" को "ऑर्डर" से बदल दें, और आप टेबल को वैसे ही भर देंगे जैसे हमने पोस्ट की शुरुआत में मूल आंकड़े में दिया था।

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

एक OLTP दुनिया में ग्रैन्युलैरिटी

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

बिंदु प्रदर्शित करने के लिए पूर्ण SQL स्क्रिप्ट DemoLowGranularity.sql प्राप्त की जा सकती है।