डीबीएमएस आणि डेटा वेअरहाऊसिंग (अच्युत गोडबोले)

अच्युत गोडबोले achyut.godbole@gmail.com
रविवार, 25 ऑगस्ट 2019

डीबीएमएस डेटा इंटिग्रिटीचा प्रश्न सोडवतं. कुठलंही डीबीएमएसचं पॅकेज आपल्याला ट्रान्झॅक्शनची व्याख्या करू देतं. उदाहरणार्थ, आपल्या उदाहरणात ‘एका अकौंटचं डेबिट करणं आणि दुसऱ्या अकौंटचं क्रेडिट करणं हे मिळून एक ट्रान्झॅक्शन आहे’ असं आपण डीबीएमएसला जाहीर करू शकतो. मात्र, हे ट्रान्झॅक्शन म्हणजे एक युनिट असं समजलं जातं. म्हणजे एक तर ते अजिबात होणारच नाही आणि झालं तर पूर्णपणे होईल याची शाश्वती डीबीएमएस आपल्याला देतं. यालाच ‘अॅटॉमिसिटी’ म्हणतात. डीबीएमएसमध्ये डेटा कन्सिस्टन्सी किंवा डेटा इंटिग्रिटी साधली जाते.

डीबीएमएस डेटा इंटिग्रिटीचा प्रश्न सोडवतं. कुठलंही डीबीएमएसचं पॅकेज आपल्याला ट्रान्झॅक्शनची व्याख्या करू देतं. उदाहरणार्थ, आपल्या उदाहरणात ‘एका अकौंटचं डेबिट करणं आणि दुसऱ्या अकौंटचं क्रेडिट करणं हे मिळून एक ट्रान्झॅक्शन आहे’ असं आपण डीबीएमएसला जाहीर करू शकतो. मात्र, हे ट्रान्झॅक्शन म्हणजे एक युनिट असं समजलं जातं. म्हणजे एक तर ते अजिबात होणारच नाही आणि झालं तर पूर्णपणे होईल याची शाश्वती डीबीएमएस आपल्याला देतं. यालाच ‘अॅटॉमिसिटी’ म्हणतात. डीबीएमएसमध्ये डेटा कन्सिस्टन्सी किंवा डेटा इंटिग्रिटी साधली जाते.

फाइल मॅनेजमेंट सिस्टिम्समध्ये (FMS-एफएमएस) डेटा इंटिग्रिटीचा प्रश्न सुटत नव्हता. काय होता हा प्रश्न? एका उदाहरणावरून हे स्पष्ट होईल. समजा आपल्याकडे अकौंटसच्या दोन फाईल्स आहेत. आता समजा एक ट्रान्झॅक्शन झाल्यावर एका फाइलमधलं अकौंट डेबिट करायचा आहे आणि दुसऱ्या फाइलमधलं अकौंट तेवढ्याच किंमतीनं क्रेडिट करायचंय. आपला प्रोग्रॅम तशा सूचना एफएमएसला देतो. एफएमएस त्यातली पहिली फाइल उघडतं आणि त्यातलं अकौंट डेबिट करतं; पण त्याचवेळी वीज जाते आणि प्रोग्रॅम थांबतो. आता काय करायचं? जर वीज आल्यावर तो प्रोग्रॅम पुन्हा चालवला, तर तो सुरवातीपासून सुरू करावा लागेल आणि त्यामुळं पहिल्या फाइलमधलं ते अकौंट दोनदा डेबिट होईल. यामुळे त्यात इनकन्सिस्टन्सी निर्माण होईल आणि डेटा इंटिग्रिटी बिघडेल. बरं, आपण ते ट्रान्झॅक्शन सोडून पुढच्या ट्रान्झॅक्शनपासून सुरवातही करू शकत नाही. याचं कारण पहिल्या फाइलमधलं ते अकौंट एकदा डेबिट झालं आहे. हाच तो डेटा इंटिग्रिटीचा प्रश्न.
त्यानंतर डेटा बेस मॅनेजमेंट सिस्टिम्स (DBMS-डीबीएमएस) आल्या. एफएमएस आणि डीबीएमएस या दोघांमध्ये अनेक फरक होते. मात्र, त्यातला एक महत्त्वाचा फरक म्हणजे डीबीएमएस डेटा इंटिग्रिटीचा प्रश्न सोडवतं. कुठलंही डीबीएमएसचं पॅकेज आपल्याला ट्रान्झॅक्शनची व्याख्या करू देतं. उदाहरणार्थ, आपल्या उदाहरणात ‘एका अकौंटचं डेबिट करणं आणि दुसऱ्या अकौंटचं क्रेडिट करणं हे मिळून एक ट्रान्झॅक्शन आहे’ असं आपण डीबीएमएसला जाहीर करू शकतो. मात्र, हे ट्रान्झॅक्शन म्हणजे एक युनिट असं समजलं जातं. म्हणजे एक तर ते अजिबात होणारच नाही आणि झालं तर पूर्णपणे होईल याची शाश्वती डीबीएमएस आपल्याला देतं. यालाच ‘अॅटॉमिसिटी’ म्हणतात. त्यामुळे जर एक अकौंट डेबिट केल्यावर वीज गेली, तरी पुन्हा प्रोग्रॅम सुरू केल्यावर डीबीएमएस पहिल्या अकौंटचा अपडेट रोलबॅक करू शकतं. यासाठी ते अकौंट डेबिट होण्याअगोदरची त्या अकौंटची व्हॅल्यू डीबीएमएस स्टोअर करत असतं; आणि वीज गेली तर वीज पुन्हा आल्यावर त्या अकौंटची ती स्टोअर केलेली पूर्वीची व्हॅल्यू वापरून ते डेबिट रद्दबादल ठरवतं आणि मग पुन्हा ते पूर्ण ट्रान्झॅक्शन पूर्ण करू शकतं. म्हणून डीबीएमएसमध्ये डेटा कन्सिस्टन्सी किंवा डेटा इंटिग्रिटी साधली जाते. डीबीएमएसचे इतरही अनेक फायदे आहेत. म्हणून एफएमएस न वापरता बहुतांशी लोक डीबीएमएसच वापरतात.
या डीबीएमएसमध्ये तीन प्रकार आहेत. हायरार्किकल, नेटवर्क आणि रिलेशनल. यातलं हायरार्किकल आणि नेटवर्क डीबीएमएस १९७० च्या दशकात खूप गाजलं. आयबीएम मेनफ्रेमवर आयएमएस नावाची एक हायरार्किकल आणि आयडीएमएस नावाची एक नेटवर्क डीबीएमएस त्याकाळी लोक खूप वापरत. पण त्यानंतर रिलेशनल डीबीएमएस अवतरली आणि बाकीच्या दोन मागे पडत गेल्या. आज ओरॅकल, सायबेस, SQL सर्व्हर, आयबीएम DB2 आणि विनामूल्य मिळणारं my SQL, MariaDB आणि Postgress अशा सगळ्या रिलेशनल डीबीएमएस किंवा आरडीबीएमएस आहेत. या डेटाबेसमध्ये आपण टेबलच्या स्वरूपात आपल्या डेटाबेसची रचना करू शकतो. यानंतर आपण त्यांच्यावर प्रश्न विचारून उत्तरंही मिळवू शकतो. यासाठी जवळपास सगळ्या आरडीबीएमएस स्ट्रक्चर्ड क्वेरी लँग्वेज (SQL) वापरतात. समजा आपला पूर्वीचाच कस्टमर डेटाबेस वापरतोय. तो कस्टमर टेबल-१ मध्ये दाखवलाय.

कस्टमर टेबल १
ग्राहक क्रमाक ग्राहकाचं नाव पत्ता शहर मोबाईल नंबर येणं (रु.)
CA001 अनंत गोरे - मुंबई ९४२----१११ १०००
CA002 पंकज पारेख - पुणे ९५२----२२२ ५०००
CA003 शीला अय्यर - मुंबई ९८१----३३३ १००००
CA004 दीपक भाटिया - पुणे ९८२----४४४ १२०००

आता आपण SQL वापरत असलेल्या आरडीबीएमएसला ‘मुंबईत राहणाऱ्या ग्राहकांची नावं द्या’ अशी क्वेरी विचारली, तर आपल्याला
अनंत गोरे
शीला अय्यर
अशी उत्तरं मिळतील.
याशिवाय आपण जास्त गुंतागुंतीचे प्रश्नही (क्वेरीज) SQL वापरत असणाऱ्या आरडीबीएमएसला विचारू शकतो. उदाहरणार्थ, ‘पुण्याला राहणाऱ्या आणि ज्यांचं येणं ९००० रुपयांपेक्षा जास्त आहे अशा ग्राहकांचे मोबाईल नंबर द्या’ असं SQL वापरणाऱ्या आरडीबीएमएसला विचारलं, तर तो
९८२----४४४ असं उत्तर देईल.
SQL मध्ये यापेक्षा खूपच गुंतागुंतीच्या सोयी असतात. त्यात दोन टेबल्स एकत्र करूनही (जॉईन) उत्तरं देण्याची सोय असते. समजा आपल्याकडे पूर्वी दिलेल्या कस्टमर टेबलाबरोबरच एक ‘कस्टमर ऑर्डर टेबल’ आहे. त्यात कस्टमरनं आपल्याला दिलेल्या प्रत्येक ऑर्डरसाठी एक रेकॉर्ड (ओळ किंवा रो) आहे. त्यात ग्राहक क्रमांक, ऑर्डर नंबर, ऑर्डर केलेला दिवस, डिलिव्हरीचा पत्ता, ऑर्डरची व्हॅल्यू वगैरे फिल्डस् आहेत. ते टेबल-२ खाली दिल्याप्रमाणं दिसेल :

ऑर्डर टेबल-२
ग्राहक नंबर ऑर्डर नंबर ऑर्डरचा दिवस डिलिव्हरीचा पत्ता ऑर्डर व्हॅल्यू
CA001 001 - - ५००
CA001 009 - - १०००
CA001 011 - - २०००
CA004 002 - - ८००

आता या दोन टेबल्समध्ये ग्राहक नंबर हे फिल्ड म्हणजे एक कॉमन दुवा आहे. हा ग्राहक नंबर हीच किल्ली (की) जर दोन्ही टेबल्समध्ये ठेवली आणि वापरली असेल, तर ती वापरून आपल्याला दोन टेबल्स जॉईन करता येतात आणि काही जास्त गुंतागुंतीच्या क्वेरीजची उत्तरंही देता येतात.
अशाच इतरही गोष्टी करता येतात. उदाहरणार्थ, समजा टेबल-१ वर कस्टमरच्या नावावर एक इंडेक्स ठेवलाय आणि टेबल-२ वर कस्टमर नंबरवर इंडेक्स ठेवलाय असं असेल, आणि ‘अनंत गोरे या ग्राहकाच्या सगळ्या ऑर्डर्सच्या व्हॅल्यूची बेरीज द्या’ अशी क्वेरी असेल, तर SQL पहिल्या टेबलमधला ग्राहकाच्या नावावरचा इंडेक्स वाचेल, त्यातलं अनंत गोरे हे नाव शोधेल, त्यानंतर त्या टेबलमध्ये अनंत गोरेचा ग्राहक नंबर शोधेल, तो त्याला CA001 असा मिळेल. आता हा नंबर वापरून दुसऱ्या म्हणजे ऑर्डर टेबलमध्ये ग्राहक नंबरचा इंडेक्स वापरून अनंत गोरेच्या (म्हणजे ग्राहक नंबर CA001च्या) सगळ्या ऑर्डर्सची रेकॉर्डस् वाचेल; आणि त्यातल्या प्रत्येक ऑर्डरची व्हॅल्यू किती आहे जे बघेल आणि मग त्यांची बेरीज करून आपल्याला ५०० + १००० + २००० म्हणजे ३५०० असं उत्तर देईल.
SQL आणि आरडीबीएमएस यांच्यापेक्षा बरंच काही करू शकतात. त्यातला डेटा जरी टेबल्सच्या स्वरूपात ठेवला असला, तरी तो अॅक्सेस करण्यासाठी ते चेन्स किंवा पॉइंटर्स, रिंग्ज, ट्रीज, क्यूज, स्टॅक्स किंवा इंडेक्सेस अशा अनेक पद्धती वापरतात. यातलं इंडेक्स म्हणजे काय हे आपण बघितलेलंच आहे. इंडेक्सच सगळ्यात जास्त प्रमाणात वापरले जातात; पण इतरही पद्धती वापरल्या जातात. या पद्धतींना ‘डेटा स्ट्रक्चर्स’ असं म्हणतात. या सगळ्यांविषयी इथं सविस्तर बोलता येणार नाही; पण आपण उदाहरण म्हणून पॉइंटर्सविषयी बोलूया.
चेन्स किंवा पॉइंटर्स समजावून सांगायचं म्हणजे शाळेतले दिवस आठवा. एखाद्या पुस्तकात पहिल्याच पानावर लिहायचं, की ‘तेहतिसाव्या पानावर जा. तिथं एक गंमत सापडेल.’ मग आपण तेहतिसाव्या पानावर जातो. तिथं लिहिलेलं असतं, की ‘छप्पन्नाव्या पानावर जा; तिथं मजा आहे’....... असं करत करत आपण ८-१० पानं उलटून उत्कंठेनं शेवटचं पान उघडतो, तेव्हा तिथं लिहिलेलं असतं, ‘कसं उल्लू बनवलं? उगाचच का पानं पलटवताय?’ ही झाली लिंक्ड लिस्ट किंवा चेन. यात एका पानावर पुढच्या पानाचा जो नंबर दिलेला असतो, त्यालाच ‘पॉइंटर’ असं म्हणतात. आणि शेवटी ‘कसं उल्लू बनवलं?’ हा संदेश आहे, तिथं ती साखळी (चेन किंवा लिंक्ड लिस्ट) संपते.
डेटाबेसमध्ये हीच पद्धत वापरता येते. उदाहरणार्थ, कुठल्याही ग्राहकाच्या ऑर्डर्स वेगवेगळ्या वेळी निर्माण झालेल्या असल्यामुळे ऑर्डर्सच्या डेटाबेसमध्ये त्या एकत्र नसतात. ज्या ज्या वेळी त्या तयार होतात, त्याप्रमाणे ऑर्डर्सच्या टेबलच्या शेवटी त्या जोडल्या जातात. जर ऑर्डर्सच्या डेटाबेसवर आपण ग्राहक नंबरवर इंडेक्स ठेवला, तर आपल्याला एकाच ग्राहकानं दिलेल्या ऑर्डर्स एकापाठोपाठ वाचता येतात. मात्र, तसा इंडेक्स नसेल, तर हे पॉइंटर्स उपयोगी पडतात. अशा वेळी ग्राहकाच्या रेकॉर्डमध्ये त्यानं दिलेल्या पहिल्या ऑर्डरचा ऑर्डर्स डेटाबेसमधला जो रेकॉर्ड नंबर असेल, तो ठेवायचा. मग त्या पहिल्या ऑर्डरच्या रेकॉर्डमध्ये त्याच ग्राहकाच्या दुसऱ्या ऑर्डरचा ऑर्डर्स डेटाबेसमधला जो रेकॉर्ड नंबर असेल, तो ठेवायचा. असं करत करत त्या ग्राहकाच्या शेवटच्या ऑर्डरच्या रेकॉर्डमध्ये ती चेन किंवा लिंक्ड लिस्ट संपल्याबद्दल काहीतरी इंडिकेटर ठेवायचा. एकूण कुठलीही डीबीएमएस आतमध्ये रेकॉर्डसमधले संबंध ठेवताना कुठली डेटा स्ट्रक्चर्स वापरतात हे वापरणाऱ्याला माहीत असण्याची गरज नसते. डीबीएमएस हे ऑनलाईन ट्रान्झॅक्शन्स प्रोसेसिंगसाठी (OLTP) जास्त करून वापरतात. यामध्ये एअरलाइनमध्ये आपण सीट बुक किंवा रद्द करणं, हॉस्पिटलमध्ये रूग्णाची अॅडमिशन झाल्यावर त्याची नोंद ठेवणं, तसंच बँकिंग आणि इतर अनेक क्षेत्रातले दैनंदिन व्यवहार किंवा ट्रान्झॅक्शन्स येतात. हे व्यवस्थित व्हावं यासाठी हे डेटाबेसेस आणि हे डीबीएमएस सॉफ्टवेअर ९९.९९% सुरू किंवा ‘अप’ असावं लागतं म्हणजेच सुरळीतपणे चालावं लागतं. ते डाऊन असून चालत नाही. डीबीएमएसमध्ये डेटाबेस क्वेरीज या शक्यतोवर सध्याच्या (करंट) डेटाबेसवर केल्या जातात. पूर्वीच्या (हिस्टॉरिकल) डेटाबेसेसवर त्या क्वचितच केल्या जातात. डीबीएमएसमध्ये एकाच वेळी हजारो युजर्स असल्यामुळे (उदाहरणार्थ, एअरलाइन्स, बँक्स...) त्यांची सुरक्षितता, इंटिग्रिटी आणि रिस्पॉन्स टाईम (वेग) या गोष्टी खूप महत्त्वाच्या ठरतात.
डीबीएमएसनंतर डेटा वेअरहाउसिंगचं सॉफ्टवेअर पुढं आलं आणि लोकप्रियही झालं; पण त्यांचे उद्देश वेगळे होते. एखाद्या कंपनीकडे इतका डेटा निर्माण व्हायला लागला आणि या डेटाचा उपयोग करून फक्त ट्रान्झॅक्शन्स प्रोसेस करणं किंवा आपण विचारलेल्या प्रश्नांची उत्तरं देणं यापलीकडे त्यातले काही पॅटर्न्स शोधणं, त्यातले संबंध किंवा असोसिएशन्स शोधणं यासाठी होऊ शकतो का?.. असा विचार डोक्यात घोळायला लागला आणि त्यातूनच डेटा मायनिंगची कल्पना निघाली. मात्र, त्यासाठी डेटा हा डेटाबेसबरोबरच डेटा वेअरहाउससारख्या स्ट्रक्चरमध्ये साठवला, तर जास्त उपयोगी पडेल असं वाटायला लागलं आणि त्यातून डेटा वेअरहाउसिंग/डेटा मायनिंगची कल्पना निघाली. डेटा वेअरहाउसिंगमध्ये अनेक तऱ्हेचा डेटा येतो. डीबीएमएसमध्ये असतो तसा स्ट्रक्चर्ड डेटा असतो, तसाच कस्टमर रिव्ह्यूज किंवा कस्टमर प्रोफाईल्स, सोशल मीडियावरची संभाषणं असा अनस्ट्रक्चर्ड डेटाही त्यात असतो. उदाहरणार्थ, कुठल्याही सुपरमार्केटमध्ये पॉइंट ऑफ सेल्सच्या (POS) काउंटरवरच्या विक्रीचा डेटा, ग्राहकांच्या तक्रारी, लॉयल्टी कार्ड असणाऱ्या ग्राहकांचा डेटा आणि इतर अनेक तऱ्हेचा डेटा एकत्र करून तो डेटा वेअरहाउसमध्ये ‘लोड’ करावा लागतो. आणि कित्येकदा त्यांची ‘समरी’ ठेवावी लागते. मात्र, अशा तऱ्हेनं तयार झालेलं डेटा वेअरहाउस डेटा मायनिंगसाठी उपयोगी पडतं. यासाठी ऑनलाईन अॅनेलेटिकल प्रोसेसिंग (OLTP) ही पद्धत वापरतात. डेटा मायनिंगविषयी नंतरच्या लेखात.


स्पष्ट, नेमक्या आणि विश्वासार्ह बातम्या वाचण्यासाठी 'सकाळ'चे मोबाईल अॅप डाऊनलोड करा
Web Title: saptarang achyut godbole write dbms and data warehousing article