مدلسازی داده در مانگودیبی: یک مثال کاربردی
در حال بررسی فایلهای قدیمی دراپ باکس بودم که به مستندات برخی پروژههای قدیمی شرکت Republishan Ltd برخوردم. پروژههایی که هر چند امروزه به بازار نرسیدهاند اما در آنزمان برای بنده تجربیاتی بس ارزشمند در حوزه بانکهای اطلاعاتی نوین بخصوص کاساندرا، ردیس، مانگو و الاستیک سرچ به ارمغان آوردند که اکثر آنها را قبلاً با خوانندگان عزیز مهندسی داده به اشتراک گذاشتهام. امروز که مجدداً مستندات کامل یک سایت خرید و فروش آنلاین کاربر محور که برای مانگو طراحی شده بود را بررسی میکردم به ذهنم رسید که بهتر است بخشی از این مستندات را به عنوان الگویی برای سایر دوستانی که قصد طراحی و مدلسازی داده با مانگو دی بی دارند، منتشر کنم .
با دوست عزیزم مهندس هادی حسینی که آنزمان دفتر مالزی شرکت را مدیریت میکرد و اکنون اداره کننده گروه بین المللی متین است که در حوزه تولید نرم افزار در تهران مستقر است و به بیش از ۳۰ کشور دنیا، خدمات تخصصی نرم افزاری ارائه می کند، تماس گرفتم و کسب اجازه کردم که این مستندات را منتشر کنم که نظر مساعد ایشان، باعث نوشتن مقاله حاضر شد.
نیازسنجی عملیاتی دادهها – گام اول
در مدلسازی داده، مستقل از اینکه قرار است با چه دیتابیسی پیادهسازی شود، ابتدا باید نیازسنجی عملیاتی انجام شده و مستند شود. منظور از نیازسنجی عملیاتی داده هم تمام دادههایی است که برای کارکرد اصلی پروژه، به آنها نیاز داریم مانند لیست موجودیتها، خصوصیات آنها، پرس و جو هایی که باید پاسخ داده شوند، ارتباطات بین موجودیتها، شاخصهای مورد نیاز و مسایلی از این دست.
بنابراین در مرحله اول، میتوان با کمک گرفتن از یک فایل ورد، تک تک موجودیتها را توصیف و خصوصیات مورد نیاز آنها را ذکر کرد، روابط آنها را مشخص نمود و هر مساله غیر فنی که از دید مشتری مهم است، مستند کرد.
در این قسمت، در بخش موجودیتها، جدولی مشابه زیر برای اعضای سایت تکمیل خواهد شد :
تعیین پرس و جوها و گزارشات مورد نیاز – گام دوم
در مرحله بعد، نیازمند مشخص کردن عملیات مختلف مورد نیاز بر روی هر موجودیت، پرس و جوها و گزارشات موردنیاز به ازای هر موجودیت و نیز گزارشات کلی هستیم. در زیر مستندات ذکر شده برای موجودیت مشتری به لاتین بیان شده است :
Members collection
- Get member info by member_id/email (all info except review object)
- Insert new member
- Update by member_id (Edit info)
- Deactivate user by member_id (set status)
- authentication by email and password (signin)
- Check email is exist in database or not(for sign out)
- Update last geo location by member_id
- Update point by member_id
- Update lastactivity by member_id
- Update config.search_distance by member_id
- Update productcount by member_id
- insert review by member_id
- insert rate by member_id
- add total_positive_rate by member_id
- add total_rate by member_id
- get review object by member_id
- get list of all members from index M to N (all info-for admin report)
مدلسازی دادهها – گام سوم
در مرحله بعد و پس از مشخص شدن موجودیتها و پرس و جوها و عملیاتی که بر روی هر موجودیت باید انجام شود، به طراحی نهایی دیتابیس بر اساس دیتابیس انتخاب شده می پردازیم. تا قبل از این مرحله، تنها نیازسنجی اولیه انجام شده بود اما در این بخش، نیازمند داشتن تخصص و دانش لازم در مدلسازی دادهها هستیم.
در ادامه مثال قبل، به مستندات کامل طراحی کالکشن عضو (Member) در مانگودیبی میپردازیم که تمام جزییات لازم برای پیاده سازی آن در مانگو، در آن ذکر شده است و میتواند الگویی برای طراحی این نوع از بانکهای اطلاعاتی باشد :
در طراحی فوق، هر جا که یک فیلد خود حاوی یک سند است (منظور از سند هم یک JSON است که با {} مشخص میشود) نوع داده از نوع Object تعریف شده و تک تک اجزای تشکیل دهنده سند داخلی هم بیان شده است . مثال انتهای متن هم به خوبی بیانگر ملاحظات طراح در هنگام مدلسازی نهایی داده ها بوده است. در بخش آخر این طراحی هم شاخص هایی که برای پاسخگویی به پرس و جوهای ذکر شده در مرحله قبل به آنها نیاز داریم، ذکر شده است.
درباره روال استاندارد طراحی دیتابیس در دنیای معاصر که باید در آن هم نیازمندیهای عملیاتی دیده شود و هم نیازمندیهای تحلیلی و غیر عملیاتی، در نوشتاری جداگانه صحبت خواهم کرد و سعی میکنم یک قالب مستند آماده برای استفاده در پروژههای تجاری برای این منظور تهیه کنم.