سود:
- توانایی توضیح مدلهای دادههای مفهومی، منطقی و فیزیکی و مفاهیم نرمالسازی و تولید پیشنویسهای موجودیت-رابطه با پشتیبانی از هوش مصنوعی
- امکان پیش نویس دیکشنری داده ها، قوانین تجاری و روابط جدول با دستورات ساختاریافته و تأیید آنها در برابر سیستم واقعی
- توانایی ارزیابی انتقادی پیشنهادات طرحواره تولید شده توسط هوش مصنوعی از نظر یکپارچگی، تکینگی و انطباق با قوانین تجاری.
یک سیستم اطلاعاتی اساساً ساختاری است که داده ها را سازماندهی می کند. مدل سازی داده ها وظیفه طراحی حقایق یک کسب و کار (مشتری، سفارش، محصول، فاکتور) و ارتباط آنها با یکدیگر به صورت ساختاریافته است. یک مدل داده خوب پایه گزارش دقیق، پرس و جوهای سریع و داده های ثابت است. یک مدل بد منشأ سال ها ناهماهنگی و کار اصلاحی مکرر است. اغلب اوقات، متخصص MIS مدل را از ابتدا کدنویسی نمی کند، اما تأیید می کند که مدل با قوانین تجاری مطابقت دارد و مدل را بین واحد تجاری و فناوری اطلاعات ترجمه می کند.
مدل سازی داده ها در سه سطح انتزاعی پیش می رود. مدل مفهومی (مفهومی انگلیسی) بالاترین سطح است: چه نهادهای اصلی وجود دارند و چگونه به هم مرتبط هستند؟ "مشتری سفارش می دهد، سفارش شامل محصول می شود." هیچ جزئیات فنی وجود ندارد. مدل منطقی ویژگی ها (فیلدها)، کلیدها و انواع رابطه هر موجودیت را تعریف می کند. اما هنوز به محصول پایگاه داده خاصی وابسته نیست. مدل فیزیکی (فیزیکی انگلیسی) نسخه مشخص جداول، انواع داده ها و فهرست ها در یک پایگاه داده خاص (به عنوان مثال SQL Server، PostgreSQL) است. این سه سطح نسخههای فزایندهای از یک ایده هستند.
موجودیت-رابطه و کلیدها
زبان اصلی مدل داده، مدل Entity-Relationship (ER) است. موجودیت را می توان به عنوان یک جدول در نظر گرفت: مشتری، سفارش. ویژگی ستون جدول است: نام، ایمیل، مبلغ. رابطه نحوه اتصال موجودیت ها است: یک مشتری می تواند سفارشات زیادی داشته باشد (رابطه یک به چند).
دو مفهوم کلیدی حیاتی وجود دارد. کلید اصلی فیلدی است که هر ردیف را در جدول به طور منحصر به فرد شناسایی می کند. برای مثال CustomerID. کلید خارجی فیلدی در یک جدول است که به کلید اصلی جدول دیگر اشاره می کند. شناسه مشتری در جدول سفارش، سفارش مشتری را به هم وصل می کند. این اتصالات یکپارچگی ارجاعی را تضمین می کند: نمی توان برای مشتری که وجود ندارد سفارش داد.
نکته: هنگامی که هوش مصنوعی یک پیش نویس ER ایجاد می کند، درخواست صریح کلید اصلی برای هر جدول و کلید خارجی برای هر رابطه را آسان تر می کند. اما هر یک از کلیدهای خارجی پیشنهاد شده توسط مدل را در برابر قانون تجاری واقعی تأیید کنید: گاهی اوقات رابطه ای که فکر می کنید "یک به چند" است در واقع "بسیار به چند" است.
عادی سازی: جلوگیری از عود
عادی سازی فرآیند کاهش افزونگی و حفظ یکپارچگی با تقسیم داده ها به جداول منطقی است. هدف این است که همان اطلاعات را در یک مکان نگه دارید. به عنوان مثال، به جای اینکه آدرس مشتری را بارها و بارها در هر خط سفارش تایپ کنید، یک بار آدرس را در جدول مشتری نگه می دارید و آن را با یک کلید خارجی از سفارش پیوند می دهید. به این ترتیب، هنگامی که آدرس تغییر می کند، آن را در یک مکان به روز می کنید. در غیر این صورت صدها سفارش دارای آدرس های مختلف خواهند بود. این ناهنجاری به روز رسانی نامیده می شود.
متضاد عادیسازی، غیرعادیسازی است: اجازه دادن به عمد مقداری تکرار به خاطر سرعت گزارشدهی. در سیستم های تجاری (پایگاه داده عملیاتی)، نرمال سازی به طور کلی ترجیح داده می شود و در سیستم های گزارش دهی (انبار داده ها)، معمولاً غیرعادی سازی ترجیح داده می شود. بنابراین "عادی سازی همیشه خوب نیست"; تصمیم با توجه به هدف گرفته می شود.
دیکشنری داده ها: زبان مشترک
دیکشنری داده سندی است که معنای هر فیلد، نوع آن، محدودیت ها و قانون تجاری را تعریف می کند. فیلد "وضعیت" به چه معناست؟ چه مقادیری می تواند داشته باشد (در انتظار، تایید شده، لغو شده)؟ آیا اجباری است؟ بدون این سند، همان زمینه توسط تیم های مختلف تفسیر متفاوتی خواهد شد و گزارش مخدوش خواهد شد. فرهنگ لغت داده ها زبان سازمان و یکی از با ارزش ترین دستاوردهای حرفه ای MIS است. هوش مصنوعی می تواند به سرعت پیش نویس دیکشنری داده های اولیه را از ساختار جدول موجود استخراج کند. اما تنها واحدی که از آن دادهها استفاده میکند، معنای تجاری واقعی هر زمینه را تأیید میکند.
سه مورد کوچک: با اعداد
مورد 1 - هزینه تکرار. در یک شرکت توزیع، آدرس مشتری به طور جداگانه در هر دو جدول سفارش و فاکتور نگهداری می شد. هنگامی که یک مشتری نقل مکان کرد، آدرس تنها در یک جدول به روز می شد. 1400 فاکتور به آدرس قدیمی رفت و بازپرداخت شد. اگر آدرس در یک جدول عادی شود، یک به روز رسانی کافی است. پروژه اصلاح 2 هفته هزینه داشت.
مورد 2 - نوع نادرست رابطه. یک کارشناس MIS در یک مؤسسه آموزشی، رابطه (یک به چند) «دانشآموز به یک کلاس تعلق دارد» را در مدل تولید شده با هوش مصنوعی تأیید کرد. با این حال، دانش آموزان می توانند در بیش از یک کلاس انتخابی ثبت نام کنند. این رابطه در واقع چند به چند بود و یک جدول میانی (Record) مورد نیاز بود. این اشتباه زمانی آشکار شد که دانش آموزی در کلاس دوم ثبت نام نکرد. اگر پیشنهاد هوش مصنوعی تایید می شد، از همان ابتدا مورد توجه قرار می گرفت.
مورد 3 - ارزش فرهنگ لغت داده. مشخص شد که فیلد "وضعیت_سیاست" در یک شرکت بیمه توسط 5 تیم مختلف تفسیر متفاوتی داشته است، بنابراین همان KPI 3 نتیجه متفاوت در گزارش ها ارائه می دهد. با تهیه پیشنویس فرهنگ لغت دادههای مبتنی بر هوش مصنوعی و دستیابی به توافقی یکسان با واحد تجاری، ناهماهنگی گزارشها از بین رفت و زمان جلسه تطبیق ماهانه 60 درصد کاهش یافت.
اعلان ضعیف / اعلان قوی
اعلان ضعیف:
طراحی پایگاه داده تجارت الکترونیک
اعلان قدرتمند:
نقش شما: شما یک مدلساز داده با تجربه هستید. یک مدل داده منطقی را مطابق قوانین تجاری زیر تهیه کنید. قوانین: - برای هر موجودیت: فیلدها، کلید اصلی، فیلدهای الزامی. - برای هر رابطه: نوع (یک به چند / چند به چند) و کلید خارجی.- جدول میانی را در روابط بین چند به چند پیشنهاد دهید. اگر غیرعادیسازی عمدی را توصیه میکنید، دلیل منطقی را بنویسید. - هر قانون تجاری که از آن مطمئن نیستید برچسب [تأیید لازم است] را بزنید. قوانین تجاری: - مشتری میتواند چندین سفارش بدهد. - یک سفارش حاوی چندین محصول است. یک محصول در بسیاری از سفارشات وجود دارد.- محصولات دارای دسته بندی هستند.[قوانین دیگر...]
اعلان قدرتمند سطح مدل (منطقی)، قوانین کلیدی و رابطه، هدف عادی سازی و نقاطی که نیاز به تایید دارند را روشن می کند.
چهار قالب قابل کپی
1) پیش نویس فرهنگ لغت داده:
یک طرح کلی فرهنگ لغت داده از تعریف جدول به دست می آید. برای هر فیلد: نام، نوع، اجباری بودن آن، مقادیر ممکن، معنای تجاری (اگر پیشبینی باشد، برچسب[PREDICTION]). جدول: [DDL یا لیست فیلدها]
2) بررسی عادی سازی:
آیا خطر تکرار داده ها، ناهنجاری به روز رسانی و فرصت عادی سازی در ساختار جدول زیر وجود دارد؟ برای هر یافته، بنویسید که کدام فرم معمولی را نقض می کند و پیشنهاد خود را. ساختار: [متن]
3) پیش نویس ER از قانون تجارت:
قوانین تجاری زیر را به موجودیت ها، ویژگی ها و روابط ترجمه کنید. نوع هر رابطه را مشخص کنید (1-1، 1-N، N-N) و اگر N-N یک جدول میانی پیشنهاد کنید. قوانین مبهم را علامت گذاری کنید. قوانین: [متن]
4) سؤالات تأیید نوع رابطه:
برای هر رابطه در مدل داده زیر، یک سؤال تجاری "بله/خیر" ایجاد کنید که صحت نوع آن را آزمایش می کند (به عنوان مثال، "آیا یک دانش آموز می تواند همزمان در بیش از یک کلاس ثبت نام کند؟"). مدل: [متن]
نمودار مقایسه: سطوح مدل
ویژگی
مفهومی
منطقی
فیزیکی
جزئیات
حداقل
متوسط
بیشتر
کلید/رابطه
دارایی های اصلی
کلیدها تعریف شده است
از جمله شاخص/نوع
بستگی به دیتابیس داره
نه
نه
بله
مخاطب هدف
واحد تجاری
تحلیلگر
توسعه دهنده/DBA
سهم هوش مصنوعی
پیش نویس
پیش نویس قوی
پیش نویس، تایید DBA
اشتباهات رایج
- در نظر گرفتن رابطه چند به چند به عنوان یک به چند. این رایج ترین خطای مدل سازی است. اگر جدول میانی فراموش شود، سیستم نمی تواند وضعیت واقعی را حفظ کند.
- قرار دادن همه چیز در یک جدول جمع آوری تمام فیلدها در یک جدول به خاطر "سادگی" باعث ایجاد موارد تکراری و بروز ناهنجاری می شود.
- دیکشنری داده نمی نویسد. هنگامی که معنای فیلدها در ذهن باقی بماند، KPI یکسان نتایج متفاوتی به دست می دهد.
- اعتماد کورکورانه به توصیه های هوش مصنوعی در مورد انواع داده ها و محدودیت ها. مدل ممکن است یک منطقه "به اندازه کافی بزرگ" را پیشنهاد کند. قانون تجارت محدودیت های واقعی را تعیین می کند (به عنوان مثال TR ID 11 رقمی).
- عادی سازی مطلق عادی سازی بیش از حد در لایه گزارش، پرس و جو را کند می کند. هدف بسته به زمینه متفاوت است.
احتیاط: هوش مصنوعی ممکن است مدل هایی تولید کند که زیبا به نظر می رسند اما قوانین تجاری را نقض می کنند. برای هر رابطه ای که توسط مدل پیشنهاد می شود، این سوال مطرح می شود که "آیا واقعا اینگونه است؟" یک سوال تجاری بپرسید. مدل داده، اسکلت سیستم است. ترمیم شکستگی در اسکلت بعداً بسیار دشوار است.
به طور خلاصه
مدلسازی دادهها فرآیند ساختاردهی حقایق تجاری با موجودیتها، ویژگیها و روابط است و در سطوح مفهومی، منطقی و فیزیکی پیش میرود. کلیدهای اصلی و خارجی یکپارچگی ارجاعی را تضمین می کنند. عادی سازی تکرار را کاهش می دهد، اما غیرعادی سازی نیز بسته به هدف مشروع است. دیکشنری داده ها زبان مشترک سازمان است. هوش مصنوعی سرعت قابل توجهی در تولید پیش نویس های ER، فرهنگ لغت داده ها و بررسی های نرمال سازی فراهم می کند. با این حال، انواع رابطه، انواع داده ها، و معنای تجاری باید در مقابل قانون واقعی کسب و کار تایید شود. فقط به این دلیل که مدل خوب به نظر می رسد به این معنی نیست که درست است.
وظیفه کاربردی
یک "سیستم امانت کتابخانه" را در نظر بگیرید: اعضا، کتاب ها، سوابق امانت. (1) یک پیش نویس مدل منطقی تولید شده توسط اعلان قدرتمند داشته باشید. (2) نوع هر رابطه ای را که مدل پیشنهاد می کند (به طور خاص، «آیا یک عضو می تواند بیش از یک نسخه از یک کتاب داشته باشد؟») را با یک سؤال تجاری آزمایش کنید. (3) حداقل یک رابطه چند به چند را پیدا کنید و یک جدول میانی تعریف کنید. (4) خطوط فرهنگ لغت داده را برای حداقل 4 فیلد (نام، نوع، اجباری، معنای تجاری) بنویسید. (5) محدودیتی را که مدل ممکن است برازش کرده باشد برجسته کنید و توضیح دهید که چگونه آن را تأیید می کنید.
چک لیست
- [ ] کلید اصلی هر جدول تعریف شده است.
- [ ] من نوع هر رابطه را با سؤال تجاری تأیید کردم.
- [ ] من یک جدول میانی برای روابط چند به چند تعریف کردم.
- [ ] من غیرعادی سازی داده های تکراری را عادی یا توجیه کردم.
- [ ] من یک خط دیکشنری داده برای فیلدهای بحرانی نوشتم.
- [ ] من پیشنهادات نوع داده/محدودیت هوش مصنوعی را در برابر قانون تجارت تأیید کردم.