ذخیرہ کرنے کی سہولت تیار کرنا ایک طویل اور سنجیدہ کام ہے۔
کسی پروجیکٹ کی زندگی کا زیادہ تر انحصار اس بات پر ہوتا ہے کہ شروع میں آبجیکٹ ماڈل اور بنیادی ڈھانچہ کو کتنی اچھی طرح سے سوچا جاتا ہے۔
عام طور پر قبول شدہ نقطہ نظر ستارہ اسکیم کو تیسری عام شکل کے ساتھ ملانے کی مختلف شکلیں رہا ہے اور باقی ہے۔ ایک اصول کے طور پر، اصول کے مطابق: ابتدائی ڈیٹا - 3NF، نمائش - ستارہ. یہ نقطہ نظر، وقت کی جانچ پڑتال اور تحقیق کی ایک بڑی مقدار کی مدد سے، پہلی (اور بعض اوقات واحد) چیز ہے جو ایک تجربہ کار DWH ماہر کے ذہن میں آتی ہے جب یہ سوچتے ہیں کہ تجزیاتی ذخیرہ کیسا ہونا چاہیے۔
دوسری طرف، عام طور پر کاروبار اور خاص طور پر گاہک کی ضروریات تیزی سے تبدیل ہوتی ہیں، اور ڈیٹا "گہرائی میں" اور "چوڑائی" دونوں میں بڑھتا ہے۔ اور یہ وہ جگہ ہے جہاں ستارے کا بنیادی نقصان ظاہر ہوتا ہے - محدود لچک.
اور اگر آپ کی پرسکون اور آرام دہ زندگی میں DWH ڈویلپر کے طور پر اچانک:
- کام شروع ہوا "کم از کم کچھ جلدی کرنا، اور پھر ہم دیکھیں گے"؛
- ہفتے میں کم از کم ایک بار نئے ذرائع کے رابطے اور کاروباری ماڈل کے دوبارہ کام کرنے کے ساتھ، ایک تیزی سے ترقی پذیر منصوبہ ظاہر ہوا؛
- ایک ایسا گاہک ظاہر ہوا ہے جسے اندازہ نہیں ہے کہ سسٹم کو کیسا نظر آنا چاہیے اور اسے آخر کار کیا کام کرنا چاہیے، لیکن وہ تجربہ کرنے کے لیے تیار ہے اور مسلسل اس کے قریب ہوتے ہوئے مطلوبہ نتائج کو مستقل طور پر بہتر کرتا ہے۔
- پراجیکٹ مینیجر خوشخبری کے ساتھ داخل ہوا: "اور اب ہمارے پاس فرتیلی ہے!"
یا اگر آپ صرف یہ جاننے میں دلچسپی رکھتے ہیں کہ آپ اسٹوریج کی سہولیات کیسے بنا سکتے ہیں - کٹ میں خوش آمدید!
"لچک" کا کیا مطلب ہے؟
سب سے پہلے، آئیے اس بات کی وضاحت کرتے ہیں کہ "لچکدار" کہلانے کے لیے سسٹم میں کن خصوصیات کا ہونا ضروری ہے۔
علیحدہ طور پر، یہ بات قابل ذکر ہے کہ بیان کردہ خصوصیات کا خاص طور پر تعلق ہونا چاہئے۔ نظام، نہیں عمل اس کی ترقی. اس لیے، اگر آپ ایجیل کے بارے میں ایک ترقی کے طریقہ کار کے طور پر پڑھنا چاہتے ہیں، تو بہتر ہے کہ دوسرے مضامین پڑھیں۔ مثال کے طور پر، وہیں، Habré پر، بہت سارے دلچسپ مواد ہیں (جیسے и اور ).
اس کا مطلب یہ نہیں ہے کہ ترقی کا عمل اور ڈیٹا گودام کی ساخت کا مکمل طور پر کوئی تعلق نہیں ہے۔ مجموعی طور پر، ایک چست فن تعمیر کے لیے فرتیلی ذخیرہ تیار کرنا کافی آسان ہونا چاہیے۔ تاہم، عملی طور پر، کمبل اور ڈیٹا والٹ کے مطابق کلاسک DWH کی فرتیلی ترقی کے ساتھ اکثر اختیارات موجود ہیں - واٹر فال کے مطابق، ایک پروجیکٹ پر اس کی دو شکلوں میں لچک کے خوشگوار اتفاقات کے مقابلے میں۔
تو، لچکدار اسٹوریج میں کیا صلاحیتیں ہونی چاہئیں؟ یہاں تین نکات ہیں:
- ابتدائی ترسیل اور تیز رفتار تبدیلی - اس کا مطلب یہ ہے کہ مثالی طور پر پہلا کاروباری نتیجہ (مثال کے طور پر، پہلی ورکنگ رپورٹس) کو جلد از جلد حاصل کیا جانا چاہیے، یعنی اس سے پہلے کہ پورے نظام کو مکمل طور پر ڈیزائن اور لاگو کیا جائے۔ مزید برآں، ہر بعد کی نظرثانی میں بھی کم سے کم وقت لگنا چاہیے۔
- تکراری تطہیر - اس کا مطلب یہ ہے کہ ہر بعد کی بہتری کو مثالی طور پر اس فعالیت کو متاثر نہیں کرنا چاہئے جو پہلے سے کام کر رہی ہے۔ یہ وہ لمحہ ہے جو اکثر بڑے منصوبوں پر سب سے بڑا ڈراؤنا خواب بن جاتا ہے - جلد یا بدیر، انفرادی اشیاء اتنے زیادہ رابطے حاصل کرنا شروع کر دیتی ہیں کہ موجودہ ٹیبل میں فیلڈ شامل کرنے کے بجائے قریبی کاپی میں منطق کو مکمل طور پر دہرانا آسان ہو جاتا ہے۔ اور اگر آپ حیران ہیں کہ موجودہ اشیاء پر ہونے والی بہتری کے اثرات کا تجزیہ کرنے میں خود بہتری سے زیادہ وقت لگ سکتا ہے، تو غالباً آپ نے ابھی تک بینکنگ یا ٹیلی کام کے بڑے ڈیٹا گوداموں کے ساتھ کام نہیں کیا ہے۔
- بدلتے ہوئے کاروباری تقاضوں کو مسلسل ڈھالنا - مجموعی آبجیکٹ کا ڈھانچہ صرف ممکنہ توسیع کو مدنظر رکھتے ہوئے ڈیزائن نہیں کیا جانا چاہئے، بلکہ اس امید کے ساتھ کہ اس اگلی توسیع کی سمت ڈیزائن کے مرحلے پر خواب میں بھی نہیں دیکھی جا سکتی تھی۔
اور ہاں، ان تمام ضروریات کو ایک نظام میں پورا کرنا ممکن ہے (یقیناً، بعض صورتوں میں اور کچھ تحفظات کے ساتھ)۔
ذیل میں میں ڈیٹا گوداموں کے لیے دو مقبول ترین چست ڈیزائن طریقوں پر غور کروں گا۔ اینکر ماڈل и ڈیٹا والٹ. بریکٹ سے باہر رہ گئی ایسی بہترین تکنیکیں ہیں، مثال کے طور پر، EAV، 6NF (اپنی خالص شکل میں) اور NoSQL حل سے متعلق ہر چیز - اس لیے نہیں کہ وہ کسی حد تک بدتر ہیں، اور اس لیے بھی نہیں کہ اس صورت میں مضمون کو حاصل کرنے کا خطرہ ہو گا۔ اوسط ڈسسر کا حجم۔ یہ صرف اتنا ہے کہ یہ سب کچھ قدرے مختلف طبقے کے حل سے متعلق ہے - یا تو ان تکنیکوں سے جو آپ مخصوص معاملات میں استعمال کر سکتے ہیں، قطع نظر اس کے کہ آپ کے پروجیکٹ کے مجموعی فن تعمیر (جیسے EAV)، یا عالمی سطح پر دیگر معلومات کے ذخیرہ کرنے کے نمونے (جیسے گراف ڈیٹا بیس) اور دیگر اختیارات NoSQL)۔
"کلاسیکی" نقطہ نظر کے مسائل اور لچکدار طریقہ کار میں ان کا حل
"کلاسیکی" نقطہ نظر سے میرا مطلب اچھا پرانا ستارہ ہے (بنیادی پرتوں کے مخصوص نفاذ سے قطع نظر، کمبال، انمون اور سی ڈی ایم کے پیروکار مجھے معاف کریں)۔
1. کنکشن کی سخت کارڈنلٹی
یہ ماڈل ڈیٹا کی واضح تقسیم پر مبنی ہے۔ طول و عرض и حقائق. اور یہ، لات، منطقی ہے - سب کے بعد، مقدمات کی بھاری اکثریت میں اعداد و شمار کا تجزیہ بعض حصوں (جہتوں) میں مخصوص عددی اشارے (حقائق) کے تجزیہ پر آتا ہے۔
اس صورت میں، اشیاء کے درمیان روابط غیر ملکی کلید کا استعمال کرتے ہوئے میزوں کے درمیان تعلقات کی صورت میں قائم ہوتے ہیں۔ یہ بالکل فطری نظر آتا ہے، لیکن فوری طور پر لچک کی پہلی حد کی طرف جاتا ہے۔ کنکشن کی اہمیت کی سخت تعریف.
اس کا مطلب یہ ہے کہ میز کے ڈیزائن کے مرحلے پر، آپ کو متعلقہ اشیاء کے ہر جوڑے کے لیے درست طریقے سے تعین کرنا چاہیے کہ آیا وہ کئی سے کئی، یا صرف 1 سے کئی، اور "کس سمت" سے متعلق ہیں۔ یہ براہ راست تعین کرتا ہے کہ کس ٹیبل میں بنیادی کلید ہوگی اور کس میں غیر ملکی کلید ہوگی۔ نئے تقاضے موصول ہونے پر اس رویہ کو تبدیل کرنا ممکنہ طور پر بنیاد کو دوبارہ کام کرنے کا باعث بنے گا۔
مثال کے طور پر، "نقد رسید" آبجیکٹ کو ڈیزائن کرتے وقت، سیلز ڈیپارٹمنٹ کے حلف پر بھروسہ کرتے ہوئے، آپ نے کارروائی کا امکان ظاہر کیا۔ کئی چیک پوزیشنوں کے لیے ایک پروموشن (لیکن اس کے برعکس نہیں):
اور کچھ عرصے بعد، ساتھیوں نے مارکیٹنگ کی ایک نئی حکمت عملی متعارف کرائی جس میں وہ اسی پوزیشن پر کام کر سکتے ہیں۔ ایک ہی وقت میں کئی پروموشنز. اور اب آپ کو رشتہ کو علیحدہ آبجیکٹ میں الگ کرکے ٹیبلز میں ترمیم کرنے کی ضرورت ہے۔
(تمام اخذ کردہ اشیاء جن میں پروموشن چیک جوائن کیا گیا ہے انہیں بھی بہتر کرنے کی ضرورت ہے)۔
ڈیٹا والٹ اور اینکر ماڈل میں تعلقات
اس صورتحال سے بچنا کافی آسان نکلا: ایسا کرنے کے لیے آپ کو سیلز ڈیپارٹمنٹ پر بھروسہ کرنے کی ضرورت نہیں ہے۔ تمام کنکشن ابتدائی طور پر علیحدہ جدولوں میں محفوظ کیے جاتے ہیں۔ اور اس پر بہت سے سے کئی تک عمل کریں۔
یہ طریقہ تجویز کیا گیا تھا۔ ڈین لنسٹڈ تمثیل کے حصے کے طور پر ڈیٹا والٹ اور مکمل حمایت کی لارس رون بیک в اینکر ماڈل.
نتیجے کے طور پر، ہمیں لچکدار طریقہ کار کی پہلی مخصوص خصوصیت ملتی ہے:
آبجیکٹ کے درمیان تعلقات والدین کی ہستیوں کی صفات میں محفوظ نہیں ہوتے بلکہ یہ ایک الگ قسم کی چیز ہیں۔
В ڈیٹا والٹ ایسی جڑنے والی میزیں کہلاتی ہیں۔ لنکاور اندر اینکر ماڈل - ٹائی. پہلی نظر میں، وہ بہت ملتے جلتے ہیں، اگرچہ ان کے اختلافات نام کے ساتھ ختم نہیں ہوتے ہیں (جس پر ذیل میں تبادلہ خیال کیا جائے گا). دونوں فن تعمیر میں، لنک ٹیبل لنک کر سکتے ہیں اداروں کی کوئی بھی تعداد (ضروری نہیں کہ 2)۔
یہ بظاہر فالتو پن ترمیم کے لیے اہم لچک فراہم کرتا ہے۔ اس طرح کا ڈھانچہ نہ صرف موجودہ روابط کی بنیادی حیثیت میں تبدیلیوں کے لیے بلکہ نئے کے اضافے کے لیے بھی روادار ہو جاتا ہے - اگر اب چیک پوزیشن میں کیشیئر سے بھی کوئی ربط ہے جس نے اسے توڑا تھا، تو اس طرح کے لنک کی ظاہری شکل آسانی سے ظاہر ہو جائے گی۔ کسی بھی موجودہ اشیاء اور عمل کو متاثر کیے بغیر موجودہ ٹیبلز پر ایک ایڈ آن بنیں۔
2. ڈیٹا ڈپلیکیشن
لچکدار فن تعمیر کے ذریعہ حل ہونے والا دوسرا مسئلہ کم واضح ہے اور پہلی جگہ میں موروثی ہے۔ SCD2 قسم کی پیمائش (دوسری قسم کے جہتوں کو آہستہ آہستہ تبدیل کرنا)، حالانکہ نہ صرف وہ۔
ایک کلاسک گودام میں، ایک طول و عرض عام طور پر ایک ٹیبل ہوتا ہے جس میں سروگیٹ کلید (بطور PK) اور الگ کالموں میں کاروباری کلیدوں اور صفات کا ایک سیٹ ہوتا ہے۔
اگر کوئی طول و عرض ورژن سازی کو سپورٹ کرتا ہے تو، ورژن کی درستگی کی حدود کو فیلڈز کے معیاری سیٹ میں شامل کیا جاتا ہے، اور کئی ورژن ماخذ میں ایک قطار کے لیے مخزن میں ظاہر ہوتے ہیں (ورژن کردہ صفات میں ہر تبدیلی کے لیے ایک)۔
اگر کسی جہت میں کم از کم ایک بار بار تبدیل ہونے والی ورژن والی خصوصیت شامل ہے، تو ایسی جہت کے ورژنز کی تعداد متاثر کن ہوگی (چاہے باقی صفات ورژن شدہ نہ ہوں یا کبھی تبدیل نہ ہوں)، اور اگر ایسی کئی صفات ہوں تو ورژن کی تعداد ان کی تعداد سے تیزی سے بڑھیں۔ یہ طول و عرض ڈسک کی ایک خاصی جگہ لے سکتا ہے، حالانکہ اس کے ذخیرہ کردہ ڈیٹا کا زیادہ تر حصہ دوسری قطاروں سے ناقابل تغیر وصف کی قدروں کی نقل ہے۔
ایک ہی وقت میں، یہ بھی اکثر استعمال کیا جاتا ہے denormalization - کچھ اوصاف جان بوجھ کر ایک قدر کے طور پر محفوظ کیے جاتے ہیں، نہ کہ کسی حوالہ کتاب یا کسی اور جہت کے لنک کے طور پر۔ یہ نقطہ نظر ڈیٹا تک رسائی کو تیز کرتا ہے، ایک طول و عرض تک رسائی حاصل کرتے وقت شمولیت کی تعداد کو کم کرتا ہے۔
عام طور پر اس کی طرف جاتا ہے۔ ایک ہی معلومات کو بیک وقت کئی جگہوں پر محفوظ کیا جاتا ہے۔. مثال کے طور پر، رہائش کے علاقے اور کلائنٹ کے زمرے کے بارے میں معلومات بیک وقت "کلائنٹ" کے طول و عرض اور "خریداری"، "ڈیلیوری" اور "کال سینٹر کالز" کے حقائق کے ساتھ ساتھ "کلائنٹ - کلائنٹ مینیجر" میں محفوظ کی جا سکتی ہیں۔ " لنک ٹیبل۔
عام طور پر، اوپر بیان کردہ باقاعدہ (غیر ورژن والے) طول و عرض پر لاگو ہوتا ہے، لیکن ورژن والے میں ان کا پیمانہ مختلف ہو سکتا ہے: کسی چیز کے نئے ورژن کا ظہور (خاص طور پر ماضی میں) نہ صرف تمام متعلقہ چیزوں کی تازہ کاری کا باعث بنتا ہے۔ ٹیبلز، لیکن متعلقہ اشیاء کے نئے ورژن کی جھلکتی ہوئی ظاہری شکل تک - جب ٹیبل 1 کو ٹیبل 2 بنانے کے لیے استعمال کیا جاتا ہے، اور ٹیبل 2 کو ٹیبل 3 وغیرہ بنانے کے لیے استعمال کیا جاتا ہے۔ یہاں تک کہ اگر ٹیبل 1 کا ایک بھی وصف ٹیبل 3 کی تعمیر میں شامل نہیں ہے (اور دوسرے ذرائع سے حاصل کردہ ٹیبل 2 کی دیگر صفات شامل ہیں)، اس تعمیر کو ورژن بنانے سے کم از کم اضافی اوور ہیڈ اور زیادہ سے زیادہ اضافی تک پہنچ جائے گی۔ جدول 3 میں ورژن۔ جس کا اس سے کوئی لینا دینا نہیں ہے، اور سلسلہ نیچے۔
3. دوبارہ کام کی نان لائنر پیچیدگی
ایک ہی وقت میں، دوسرے کی بنیاد پر بنایا گیا ہر نیا اسٹور فرنٹ ان جگہوں کی تعداد میں اضافہ کرتا ہے جہاں ETL میں تبدیلیاں کیے جانے پر ڈیٹا "مختلف" ہو سکتا ہے۔ اس کے نتیجے میں، ہر بعد کی نظرثانی کی پیچیدگی (اور مدت) میں اضافہ ہوتا ہے۔
اگر اوپر شاذ و نادر ہی ترمیم شدہ ETL عملوں کے ساتھ نظام کی وضاحت کرتا ہے، تو آپ اس طرح کے نمونے میں رہ سکتے ہیں - آپ کو صرف اس بات کو یقینی بنانا ہوگا کہ تمام متعلقہ اشیاء میں نئی ترمیمات درست طریقے سے کی گئی ہیں۔ اگر نظر ثانی کثرت سے ہوتی ہے، تو اتفاقی طور پر کئی کنکشنز کے "غائب" ہونے کا امکان نمایاں طور پر بڑھ جاتا ہے۔
اگر، اس کے علاوہ، ہم اس بات کو مدنظر رکھتے ہیں کہ "ورژن شدہ" ETL "غیر ورژن والے" کے مقابلے میں نمایاں طور پر زیادہ پیچیدہ ہے، تو اس پوری سہولت کو اکثر اپ ڈیٹ کرتے وقت غلطیوں سے بچنا کافی مشکل ہو جاتا ہے۔
ڈیٹا والٹ اور اینکر ماڈل میں اشیاء اور صفات کو ذخیرہ کرنا
لچکدار فن تعمیر کے مصنفین کی طرف سے تجویز کردہ نقطہ نظر کو مندرجہ ذیل طور پر مرتب کیا جا سکتا ہے:
جو تبدیلیاں وہی رہتی ہیں اس سے الگ کرنا ضروری ہے۔ یعنی اوصاف سے الگ کیز کو اسٹور کریں۔
تاہم، کسی کو الجھنا نہیں چاہئے۔ ورژن نہیں ہے کے ساتھ وصف غیر تبدیل شدہ: پہلا اپنی تبدیلیوں کی تاریخ کو ذخیرہ نہیں کرتا ہے، لیکن تبدیل کر سکتا ہے (مثال کے طور پر، ان پٹ کی غلطی کو درست کرتے وقت یا نیا ڈیٹا وصول کرتے وقت)؛ دوسرا کبھی تبدیل نہیں ہوتا ہے۔
نقطہ نظر اس بات پر مختلف ہے کہ ڈیٹا والٹ اور اینکر ماڈل میں بالکل کس چیز کو ناقابل تغیر سمجھا جا سکتا ہے۔
آرکیٹیکچرل نقطہ نظر سے ڈیٹا والٹ، کو غیر تبدیل شدہ سمجھا جا سکتا ہے۔ چابیاں کا پورا سیٹ - قدرتی (تنظیم کا TIN، سورس سسٹم میں پروڈکٹ کوڈ وغیرہ) اور سروگیٹ۔ اس صورت میں، باقی صفات کو ماخذ اور/یا تبدیلیوں کی تعدد کے مطابق گروپوں میں تقسیم کیا جا سکتا ہے اور ہر گروپ کے لیے علیحدہ جدول رکھیں ورژن کے ایک آزاد سیٹ کے ساتھ۔
تمثیل میں اینکر ماڈل غیر تبدیل شدہ سمجھا جاتا ہے صرف سروگیٹ کلید جوہر. باقی سب کچھ (بشمول قدرتی چابیاں) اس کی صفات کا صرف ایک خاص معاملہ ہے۔ جس میں تمام صفات بطور ڈیفالٹ ایک دوسرے سے آزاد ہیں۔تو ہر ایک وصف کے لیے a علیحدہ میز.
В ڈیٹا والٹ ہستی کی چابیاں پر مشتمل میزیں کہلاتی ہیں۔ حبامی. حب میں ہمیشہ فیلڈز کا ایک مقررہ سیٹ ہوتا ہے:
- قدرتی ہستی کی چابیاں
- سروگیٹ کلید
- ماخذ سے لنک
- شامل کرنے کا وقت ریکارڈ کریں۔
حبس میں پوسٹس کبھی تبدیل نہیں ہوتا ہے اور اس کا کوئی ورژن نہیں ہوتا ہے۔. بیرونی طور پر، حب ID-map ٹائپ ٹیبلز سے بہت ملتے جلتے ہیں جو سروگیٹس پیدا کرنے کے لیے کچھ سسٹمز میں استعمال ہوتے ہیں، تاہم، ڈیٹا والٹ میں سروگیٹس کے طور پر بزنس کیز کے سیٹ سے ہیش استعمال کرنے کی سفارش کی جاتی ہے۔ یہ نقطہ نظر ذرائع سے تعلقات اور صفات کو لوڈ کرنا آسان بناتا ہے (سروگیٹ حاصل کرنے کے لیے آپ کو مرکز میں شامل ہونے کی ضرورت نہیں ہے، آپ کو صرف قدرتی کلید کی ہیش کا حساب لگانا ہوگا)، لیکن دیگر مسائل (مثلاً، تصادم سے متعلق) پیدا کر سکتا ہے۔ , کیس اور سٹرنگ کیز وغیرہ میں نان پرنٹ ایبل حروف وغیرہ .p.) اس لیے اسے عام طور پر قبول نہیں کیا جاتا ہے۔
دیگر تمام ہستی کے اوصاف کو خصوصی جدولوں میں محفوظ کیا جاتا ہے جسے کہا جاتا ہے۔ سیٹلائٹس. ایک مرکز میں کئی سیٹلائٹ ہو سکتے ہیں جو صفات کے مختلف سیٹ محفوظ کر سکتے ہیں۔
سیٹلائٹ کے درمیان صفات کی تقسیم اصول کے مطابق ہوتی ہے۔ مشترکہ تبدیلی - ایک سیٹلائٹ میں غیر ورژن والے اوصاف کو ذخیرہ کیا جا سکتا ہے (مثال کے طور پر، تاریخ پیدائش اور ایک فرد کے لیے SNILS)، دوسرے میں - شاذ و نادر ہی تبدیل شدہ ورژن والے (مثال کے طور پر، آخری نام اور پاسپورٹ نمبر)، تیسرے میں - کثرت سے تبدیل ہونے والے (مثال کے طور پر، ترسیل کا پتہ، زمرہ، آخری آرڈر کی تاریخ، وغیرہ)۔ اس صورت میں، ورژننگ انفرادی سیٹلائٹ کی سطح پر کی جاتی ہے، نہ کہ مجموعی طور پر، اس لیے یہ مشورہ دیا جاتا ہے کہ اوصاف کو تقسیم کیا جائے تاکہ ایک سیٹلائٹ کے اندر موجود ورژنز کا ملاپ کم سے کم ہو (جس سے ذخیرہ شدہ ورژنز کی کل تعداد کم ہو جاتی ہے۔ )۔
نیز، ڈیٹا لوڈ کرنے کے عمل کو بہتر بنانے کے لیے، مختلف ذرائع سے حاصل کردہ صفات کو اکثر انفرادی سیٹلائٹ میں شامل کیا جاتا ہے۔
سیٹلائٹ حب کے ساتھ بذریعہ بات چیت کرتے ہیں۔ غیر ملکی چابی (جو 1 سے کئی کارڈنلٹی کے مساوی ہے)۔ اس کا مطلب ہے کہ متعدد انتساب اقدار (مثال کے طور پر، ایک کلائنٹ کے لیے متعدد رابطہ فون نمبرز) اس "ڈیفالٹ" فن تعمیر کے ذریعے تعاون یافتہ ہیں۔
В اینکر ماڈل چابیاں ذخیرہ کرنے والی میزیں کہلاتی ہیں۔ اینکرز. اور وہ رکھتے ہیں:
- صرف سروگیٹ چابیاں
- ماخذ سے لنک
- شامل کرنے کا وقت ریکارڈ کریں۔
اینکر ماڈل کے نقطہ نظر سے قدرتی چابیاں سمجھا جاتا ہے عام صفات. یہ آپشن سمجھنا زیادہ مشکل معلوم ہو سکتا ہے، لیکن یہ چیز کی شناخت کے لیے بہت زیادہ گنجائش فراہم کرتا ہے۔
مثال کے طور پر، اگر ایک ہی ہستی کے بارے میں ڈیٹا مختلف سسٹمز سے آ سکتا ہے، جن میں سے ہر ایک اپنی قدرتی کلید استعمال کرتا ہے۔ ڈیٹا والٹ میں، یہ کئی حبس (ایک فی ماخذ + یکجا کرنے والا ماسٹر ورژن) کی بجائے بوجھل ڈھانچے کا باعث بن سکتا ہے، جبکہ اینکر ماڈل میں، ہر ماخذ کی قدرتی کلید اس کی اپنی خصوصیت میں آتی ہے اور اسے آزادانہ طور پر لوڈ کرتے وقت استعمال کیا جا سکتا ہے۔ تمام دوسرے.
لیکن یہاں ایک مضحکہ خیز نکتہ بھی ہے: اگر مختلف نظاموں کی صفات کو ایک ہستی میں ملایا جائے تو غالباً کچھ "گلونگ" کے قواعد، جس کے ذریعہ سسٹم کو یہ سمجھنا چاہئے کہ مختلف ذرائع سے ریکارڈز ہستی کی ایک مثال سے مطابقت رکھتے ہیں۔
В ڈیٹا والٹ یہ اصول زیادہ تر ممکنہ طور پر تشکیل کا تعین کریں گے۔ ماسٹر ہستی کا "سروگیٹ مرکز" اور کسی بھی طرح سے ان حب پر اثر انداز نہیں ہوتے جو قدرتی ماخذ کی چابیاں اور ان کی اصل صفات کو محفوظ کرتے ہیں۔ اگر کسی موقع پر انضمام کے قواعد بدل جاتے ہیں (یا وہ صفات جن کے ذریعہ یہ انجام دیا جاتا ہے) کو اپ ڈیٹ کیا جاتا ہے، تو یہ سروگیٹ حبس کو دوبارہ فارمیٹ کرنے کے لیے کافی ہوگا۔
В اینکر ماڈل اس طرح کی ایک ہستی زیادہ تر ممکنہ طور پر ذخیرہ کی جائے گی۔ واحد اینکر. اس کا مطلب یہ ہے کہ تمام صفات، خواہ وہ کسی بھی ذریعہ سے آئیں، ایک ہی سروگیٹ کے پابند ہوں گے۔ غلطی سے ضم شدہ ریکارڈز کو الگ کرنا اور عام طور پر ایسے نظام میں انضمام کی مطابقت کی نگرانی کرنا بہت زیادہ مشکل ہو سکتا ہے، خاص طور پر اگر قواعد کافی پیچیدہ ہوں اور اکثر تبدیل ہوتے ہوں، اور ایک ہی وصف مختلف ذرائع سے حاصل کیا جا سکتا ہے (حالانکہ یہ یقینی طور پر ممکن ہے، چونکہ ہر ایک انتساب ورژن اپنے ماخذ کا لنک برقرار رکھتا ہے)۔
کسی بھی صورت میں، اگر آپ کے سسٹم کو فعالیت کو نافذ کرنا ہے۔ ڈپلیکیشن، ریکارڈ کو ضم کرنا اور دیگر MDM عناصر، قدرتی چابیاں کو فرتیلی طریقوں میں ذخیرہ کرنے کے پہلوؤں پر خصوصی توجہ دینے کے قابل ہے۔ یہ امکان ہے کہ بڑا ڈیٹا والٹ ڈیزائن انضمام کی غلطیوں کے لحاظ سے اچانک زیادہ محفوظ ہو جائے گا۔
اینکر ماڈل نامی ایک اضافی آبجیکٹ کی قسم بھی فراہم کرتا ہے۔ گرہ یہ بنیادی طور پر خاص ہے لنگر کی انحطاطی قسم، جس میں صرف ایک وصف ہو سکتا ہے۔ نوڈس کو فلیٹ ڈائریکٹریز (مثال کے طور پر، جنس، ازدواجی حیثیت، کسٹمر سروس کیٹیگری، وغیرہ) کو ذخیرہ کرنے کے لیے استعمال کیا جانا چاہیے۔ اینکر کے برعکس، گرہ کوئی وابستہ وصف ٹیبل نہیں ہے۔، اور اس کا واحد وصف (نام) ہمیشہ کلید کے ساتھ ایک ہی ٹیبل میں محفوظ ہوتا ہے۔ نوڈس ٹائی ٹیبلز (ٹائی) کے ذریعے اینکرز سے اسی طرح جڑے ہوتے ہیں جس طرح اینکرز ایک دوسرے سے جڑے ہوتے ہیں۔
نوڈس کے استعمال کے بارے میں کوئی واضح رائے نہیں ہے۔ مثال کے طور پر، ، جو روس میں اینکر ماڈل کے استعمال کو فعال طور پر فروغ دیتا ہے، کا خیال ہے کہ (غیر معقول طور پر نہیں) کہ کسی ایک حوالہ کتاب کے لیے یہ یقین کے ساتھ نہیں کہا جا سکتا کہ یہ ہمیشہ جامد اور سنگل سطح کا ہوگا، اس لیے بہتر ہے کہ فوری طور پر تمام اشیاء کے لیے مکمل اینکر استعمال کریں۔
ڈیٹا والٹ اور اینکر ماڈل کے درمیان ایک اور اہم فرق دستیابی ہے۔ کنکشن کی خصوصیات:
В ڈیٹا والٹ لنکس ایک ہی مکمل آبجیکٹ ہیں جیسے Hubs، اور ہو سکتے ہیں۔ اپنی صفات. میں اینکر ماڈل لنکس کا استعمال صرف اینکرز کو جوڑنے کے لیے کیا جاتا ہے۔ ان کی اپنی صفات نہیں ہوسکتی ہیں۔. اس فرق کا نتیجہ نمایاں طور پر مختلف ماڈلنگ کے طریقوں میں ہوتا ہے۔ حقائق، جس پر مزید بات کی جائے گی۔
حقیقت کا ذخیرہ
اس سے پہلے، ہم نے بنیادی طور پر پیمائش ماڈلنگ کے بارے میں بات کی تھی۔ حقائق کچھ کم واضح ہیں۔
В ڈیٹا والٹ حقائق کو ذخیرہ کرنے کے لیے ایک عام چیز ہے۔ لنک، جس کے سیٹلائٹس میں حقیقی اشارے شامل کیے گئے ہیں۔
یہ نقطہ نظر بدیہی لگتا ہے۔ یہ تجزیہ کردہ اشارے تک آسان رسائی فراہم کرتا ہے اور عام طور پر روایتی حقائق کی میز سے ملتا جلتا ہے (صرف اشارے ٹیبل میں نہیں بلکہ "پڑوسی" میں محفوظ کیے جاتے ہیں)۔ لیکن اس میں نقصانات بھی ہیں: ماڈل کی ایک عام ترمیم - حقیقت کی کلید کی توسیع - ضروری ہے لنک میں ایک نئی غیر ملکی کلید شامل کرنا. اور یہ، بدلے میں، ماڈیولرٹی کو "توڑ" دیتا ہے اور ممکنہ طور پر دیگر اشیاء میں ترمیم کی ضرورت کا سبب بنتا ہے۔
В اینکر ماڈل ایک کنکشن کی اپنی صفات نہیں ہوسکتی ہیں، اس لیے یہ طریقہ کارگر نہیں ہوگا - بالکل تمام صفات اور اشارے ایک مخصوص اینکر سے منسلک ہونے چاہئیں۔ اس سے نتیجہ آسان ہے - ہر حقیقت کو اپنے اینکر کی بھی ضرورت ہوتی ہے۔. جن چیزوں کو ہم حقائق کے طور پر سمجھنے کے عادی ہیں، ان میں سے کچھ کے لیے، یہ قدرتی لگ سکتا ہے - مثال کے طور پر، کسی خریداری کی حقیقت کو "آرڈر" یا "رسید"، کسی سیشن میں سائٹ پر جانا وغیرہ تک بالکل کم کیا جا سکتا ہے۔ لیکن ایسے حقائق بھی ہیں جن کے لیے ایسی قدرتی "کیرئیر آبجیکٹ" تلاش کرنا اتنا آسان نہیں ہے - مثال کے طور پر، ہر دن کے آغاز میں گوداموں میں سامان کی باقیات۔
اس کے مطابق، اینکر ماڈل میں فیکٹ کلید کو بڑھاتے وقت ماڈیولریٹی کے ساتھ مسائل پیدا نہیں ہوتے ہیں (اسے متعلقہ اینکر کے ساتھ صرف ایک نیا رشتہ شامل کرنا کافی ہے)، لیکن حقائق کو ظاہر کرنے کے لیے ماڈل کو ڈیزائن کرنا کم مبہم ہے؛ "مصنوعی" اینکرز ظاہر ہو سکتے ہیں۔ جو کاروباری آبجیکٹ ماڈل کو غیر واضح طریقے سے ظاہر کرتا ہے۔
لچک کیسے حاصل کی جاتی ہے۔
دونوں صورتوں میں نتیجے کی تعمیر پر مشتمل ہے نمایاں طور پر زیادہ میزیںروایتی پیمائش کے مقابلے میں۔ لیکن یہ لگ سکتا ہے۔ نمایاں طور پر کم ڈسک کی جگہ روایتی جہت کی طرح ورژن شدہ صفات کے ایک ہی سیٹ کے ساتھ۔ قدرتی طور پر، یہاں کوئی جادو نہیں ہے - یہ سب کچھ نارملائزیشن کے بارے میں ہے۔ سیٹلائٹس (ڈیٹا والٹ میں) یا انفرادی جدولوں (اینکر ماڈل) میں صفات تقسیم کرکے، ہم کم کرتے ہیں (یا مکمل طور پر ختم) دوسروں کو تبدیل کرتے وقت کچھ صفات کی قدروں کی نقل.
کے لیے ڈیٹا والٹ جیت کا انحصار سیٹلائٹ کے درمیان صفات کی تقسیم اور اس کے لیے ہوگا۔ اینکر ماڈل - فی پیمائش آبجیکٹ کے ورژن کی اوسط تعداد کے تقریبا براہ راست متناسب ہے۔
تاہم، جگہ کی بچت ایک اہم، لیکن اہم نہیں، صفات کو الگ سے ذخیرہ کرنے کا فائدہ ہے۔ رشتوں کی الگ اسٹوریج کے ساتھ، یہ نقطہ نظر اسٹور بناتا ہے ماڈیولر ڈیزائن. اس کا مطلب یہ ہے کہ اس طرح کے ماڈل میں انفرادی صفات اور پورے نئے موضوع کے علاقوں کو شامل کرنا ایسا لگتا ہے۔ سپر اسٹرکچر اشیاء کے موجودہ سیٹ پر انہیں تبدیل کیے بغیر۔ اور یہ بالکل وہی ہے جو بیان کردہ طریقہ کار کو لچکدار بناتا ہے۔
یہ ٹکڑوں کی پیداوار سے بڑے پیمانے پر پیداوار میں منتقلی سے بھی مشابہت رکھتا ہے - اگر روایتی نقطہ نظر میں ماڈل کی ہر جدول منفرد ہے اور اسے خصوصی توجہ کی ضرورت ہے، تو لچکدار طریقوں میں یہ پہلے سے ہی معیاری "حصوں" کا ایک مجموعہ ہے۔ ایک طرف، زیادہ میزیں ہیں، اور ڈیٹا کو لوڈ کرنے اور بازیافت کرنے کے عمل کو زیادہ پیچیدہ نظر آنا چاہیے۔ دوسری طرف، وہ بن جاتے ہیں عام. جس کا مطلب ہے کہ ہو سکتا ہے۔ خودکار اور میٹا ڈیٹا سے چلنے والا. سوال "ہم اسے کیسے رکھیں گے؟"، جس کا جواب ڈیزائن میں بہتری کے کام کا ایک اہم حصہ لے سکتا ہے، اب اس کے قابل نہیں ہے (نیز کام کے عمل پر ماڈل کو تبدیل کرنے کے اثرات کے بارے میں سوال )۔
اس کا مطلب یہ نہیں ہے کہ ایسے نظام میں تجزیہ کاروں کی بالکل ضرورت نہیں ہے - کسی کو اب بھی صفات کے ساتھ اشیاء کے سیٹ کے ذریعے کام کرنے کی ضرورت ہے اور یہ معلوم کرنا ہے کہ یہ سب کہاں اور کیسے لوڈ کرنا ہے۔ لیکن کام کی مقدار کے ساتھ ساتھ غلطی کا امکان اور قیمت نمایاں طور پر کم ہو جاتی ہے۔ تجزیہ کے مرحلے میں اور ETL کی ترقی کے دوران، جس میں ایک اہم حصہ میٹا ڈیٹا میں ترمیم کرنے کے لیے کم کیا جا سکتا ہے۔
تاریک پہلو
مذکورہ بالا سبھی دونوں طریقوں کو حقیقی معنوں میں لچکدار، تکنیکی طور پر ترقی یافتہ اور تکراری بہتری کے لیے موزوں بناتے ہیں۔ یقینا، "مرہم میں بیرل" بھی ہے، جس کے بارے میں مجھے لگتا ہے کہ آپ پہلے ہی اندازہ لگا سکتے ہیں.
ڈیٹا کی سڑن، جو لچکدار فن تعمیر کی ماڈیولریٹی کو زیر کرتی ہے، میزوں کی تعداد میں اضافے کا باعث بنتی ہے اور، اس کے مطابق، اوپر نمونے لینے کے وقت شامل ہونا۔ طول و عرض کی تمام خصوصیات کو حاصل کرنے کے لیے، کلاسک اسٹور میں ایک انتخاب کافی ہے، لیکن ایک لچکدار فن تعمیر کے لیے جوائن کی ایک پوری سیریز کی ضرورت ہوگی۔ مزید برآں، اگر رپورٹس کے لیے یہ تمام جوائنز پہلے سے لکھے جا سکتے ہیں، تو تجزیہ کار جو ایس کیو ایل کو ہاتھ سے لکھنے کے عادی ہیں ان کو دوہرا نقصان ہوگا۔
اس صورت حال کو آسان بنانے کے کئی حقائق ہیں:
بڑے طول و عرض کے ساتھ کام کرتے وقت، اس کی تمام صفات تقریباً کبھی ایک ساتھ استعمال نہیں ہوتیں۔ اس کا مطلب یہ ہے کہ ماڈل پر پہلی نظر میں اس سے کم جوائنز ہوسکتے ہیں۔ ڈیٹا والٹ سیٹلائٹ کو صفات مختص کرتے وقت شیئرنگ کی متوقع فریکوئنسی کو بھی مدنظر رکھ سکتا ہے۔ ایک ہی وقت میں، بنیادی طور پر لوڈنگ کے مرحلے پر سروگیٹس بنانے اور ان کی نقشہ سازی کے لیے حبس یا اینکرز کی ضرورت ہوتی ہے اور سوالات میں شاذ و نادر ہی استعمال ہوتے ہیں (یہ خاص طور پر اینکرز کے لیے درست ہے)۔
تمام جوائنز کلید کے ذریعے ہوتے ہیں۔ اس کے علاوہ، ڈیٹا کو ذخیرہ کرنے کا ایک زیادہ "کمپریسڈ" طریقہ اسکیننگ ٹیبلز کے اوور ہیڈ کو کم کر دیتا ہے جہاں اس کی ضرورت ہوتی ہے (مثال کے طور پر، انتساب کی قدر کے لحاظ سے فلٹر کرتے وقت)۔ یہ اس حقیقت کی طرف لے جا سکتا ہے کہ جوائنز کے ایک گروپ کے ساتھ معمول کے ڈیٹا بیس سے نمونے لینا ہر قطار میں کئی ورژن کے ساتھ ایک بھاری جہت کو اسکین کرنے سے بھی تیز تر ہوگا۔
مثال کے طور پر، یہاں میں مضمون میں ایک میز سے نمونے کے ساتھ اینکر ماڈل کی کارکردگی کا تفصیلی تقابلی ٹیسٹ شامل ہے۔
بہت کچھ انجن پر منحصر ہے۔ بہت سے جدید پلیٹ فارمز میں داخلی جوائن کی اصلاح کا طریقہ کار ہوتا ہے۔ مثال کے طور پر، MS SQL اور Oracle ٹیبلز پر جوائنز کو "اسکپ" کر سکتے ہیں اگر ان کا ڈیٹا دیگر جوائنز کے علاوہ کہیں استعمال نہیں ہوتا ہے اور حتمی انتخاب (ٹیبل/جوائن ایلیمینیشن) اور MPP ورٹیکا کو متاثر نہیں کرتا ہے۔ , اینکر ماڈل کے لیے ایک بہترین انجن ثابت ہوا ہے، جس سے استفسار کے منصوبے کی کچھ دستی اصلاح کی گئی ہے۔ دوسری طرف، اینکر ماڈل کو ذخیرہ کرنا، مثال کے طور پر کلک ہاؤس پر، جس میں جوائن سپورٹ محدود ہے، ابھی تک بہت اچھا خیال نہیں لگتا ہے۔
اس کے علاوہ، دونوں فن تعمیر کے لئے ہیں خصوصی حرکتیںڈیٹا تک رسائی کو آسان بنانا (استفسار کی کارکردگی کے نقطہ نظر سے اور آخری صارفین کے لیے)۔ مثال کے طور پر، پوائنٹ ان ٹائم ٹیبلز ڈیٹا والٹ میں یا خصوصی ٹیبل افعال اینکر ماڈل میں۔
مجموعی طور پر
سمجھے جانے والے لچکدار فن تعمیر کا بنیادی جوہر ان کے "ڈیزائن" کی ماڈیولریٹی ہے۔
یہ یہ پراپرٹی ہے جو اجازت دیتی ہے:
- میٹا ڈیٹا کی تعیناتی اور بنیادی ETL الگورتھم لکھنے سے متعلق کچھ ابتدائی تیاری کے بعد، فوری طور پر کسٹمر کو پہلا نتیجہ فراہم کریں۔ کچھ رپورٹس کی شکل میں جس میں صرف چند ماخذ اشیاء سے ڈیٹا شامل ہے۔ یہ ضروری نہیں ہے کہ پورے آبجیکٹ ماڈل کے بارے میں (یہاں تک کہ اوپر کی سطح پر بھی) مکمل طور پر سوچیں۔
- ڈیٹا ماڈل صرف 2-3 اشیاء کے ساتھ کام کرنا شروع کر سکتا ہے (اور مفید ہو سکتا ہے) اور پھر آہستہ آہستہ بڑھو (اینکر ماڈل نکولائی کے حوالے سے mycelium کے ساتھ اچھا موازنہ)۔
- سب سے زیادہ بہتری، بشمول موضوع کے علاقے کو بڑھانا اور نئے ذرائع شامل کرنا موجودہ فعالیت کو متاثر نہیں کرتا اور کسی ایسی چیز کے ٹوٹنے کا خطرہ نہیں لاتا جو پہلے سے کام کر رہی ہے۔.
- معیاری عناصر میں گلنے کی بدولت، اس طرح کے نظاموں میں ETL کے عمل ایک جیسے نظر آتے ہیں، ان کی تحریر الگورتھمائزیشن کی طرف لے جاتی ہے اور بالآخر، آٹومیشن.
اس لچک کی قیمت ہے۔ کارکردگی. اس کا مطلب یہ نہیں ہے کہ ایسے ماڈلز پر قابل قبول کارکردگی حاصل کرنا ناممکن ہے۔ زیادہ کثرت سے، آپ کو اپنی مطلوبہ میٹرکس حاصل کرنے کے لیے تفصیل پر زیادہ محنت اور توجہ کی ضرورت ہو سکتی ہے۔
اطلاقات
ہستی کی اقسام ڈیٹا والٹ
ڈیٹا والٹ کے بارے میں مزید معلومات:
ہستی کی اقسام اینکر ماڈل
اینکر ماڈل کے بارے میں مزید تفصیلات:
خلاصہ جدول جس میں مشترکہ خصوصیات اور سمجھے جانے والے طریقوں کے اختلافات ہیں:
ماخذ: www.habr.com