داده های معامله ای

داده های معاملاتی مربوط به معاملات سازمان است و شامل داده هایی است که ضبط می شود ، به عنوان مثال ، هنگام فروش یا خریداری یک محصول. داده های اصلی در معاملات مختلف ذکر شده است و نمونه های آن داده های مشتری ، محصول یا تهیه کننده است. به طور کلی ، داده های اصلی تغییر نمی کنند و نیازی به ایجاد با هر معامله نیست. به عنوان مثال ، اگر یک مشتری در زمان های مختلف چندین محصول را خریداری کند ، برای هر فروش باید سابقه معامله ایجاد شود ، اما داده های مربوط به مشتری یکسان باقی می ماند. شکل 12. 1 نشان می دهد که چگونه داده های اصلی بخشی از یک سابقه معامله را تشکیل می دهند. در این حالت ، هنگامی که لامپ و محصولات صندلی فروخته می شوند ، معامله به شناسه محصول مربوطه و شناسه مشتری اشاره می کند. سوابق محصول و مشتری ، اگر از قبل وجود داشته باشند ، نیازی به بازآفرینی یا اصلاح برای این معامله جدید ندارند. داده های دیگر در معامله ، مانند شناسه منحصر به فرد برای معامله (یعنی شناسه فروش) و زمان فروش نیاز به تغییر دارند. بنابراین داده های معامله به طور معمول نسبت به داده های اصلی بی ثبات تر هستند زیرا بیشتر ایجاد می شود و بیشتر تغییر می کند. توجه داشته باشید که این مثال ساده قیمت فروش واقعی در معامله و قیمت محصول را در داده های اصلی نشان می دهد. روش های مختلفی برای الگوبرداری از این وجود دارد ، اما مثال نشان می دهد که قیمت واقعی بسته به معامله می تواند تغییر کند و فقط ممکن است از قیمت محصول در داده های اصلی محاسبه شود (پس از تخفیف و غیره). معامله 003 در شکل 12. 1 نشان می دهد که تخفیف به قیمت خرده فروشی اعمال شده است.

یکی دیگر از ویژگی های کارشناسی ارشد این است که اغلب توسط واحدهای مختلف تجاری به اشتراک گذاشته می شود و مورد استفاده قرار می گیرد. به عنوان مثال ، از رکورد مشتری توسط بازاریابی و همچنین فروش استفاده می شود. هنگامی که یک واحد تجاری سوابق کارشناسی ارشد را به روز می کند و به واحد تجاری دیگر اطلاع نمی دهد ، مشکلات بوجود می آیند. به عنوان مثال ، بخش بازاریابی می تواند آدرس مشتری را به روز کند و در صورت عدم اطلاع بخش فروش ، سفارشات را می توان به یک آدرس قدیمی ارسال کرد.

اگرچه این خصوصیات کلی داده های استاد و معامله ای است ، اما مواردی وجود دارد که این انواع داده ها متفاوت رفتار می کنند و بنابراین ، این تمایز مبهم می شود. به عنوان مثال ، داده های اصلی نیز می توانند به نظر برسند که وقتی تغییر در آدرس تأمین کننده ، به عنوان مثال ، در یک رکورد رونویسی نمی شود ، اما در عوض یک رکورد جدید ایجاد می شود. یک سازمان ممکن است تصمیم بگیرد تمام آدرس های قبلی یک تأمین کننده را حفظ کند ، به خصوص اگر بخواهند جنبش تأمین کننده را تحلیل کنند. شایان ذکر است به مواردی مانند این موارد ، زیرا ممکن است بهتر باشد راه حل های معامله ای را برای مشکلات موجود در این نوع داده اعمال کنید تا به درستی مدیریت شود.

ACTION TIP

همیشه فرض نکنید که داده های اصلی فقط باید با راه حل های مرتبط با داده های اصلی رفتار شوند ، به خصوص اگر داده های اصلی مانند داده های معامله رفتار کنند.

هنگام در نظر گرفتن محیط اطلاعات برای فرآیند TIRM ، داده های معامله ای اغلب در انبارهای داده و سیستم های نقطه فروش که در آن معاملات انجام می شود ، یافت می شود. داده های اصلی اغلب در نرم افزار مدیریت ارتباط با مشتری (CRM) ، نرم افزار مدیریت چرخه زندگی (PLM) و سیستم های مدیریت روابط تأمین کننده (SRM) یافت می شود. با این حال ، می توان با ردیابی از سوابق معامله ای که به مشتریان ، محصولات ، تأمین کنندگان و غیره اشاره دارد ، شناسایی کرد. اگر متوجه شدید که تنها منبع داده های اصلی در سوابق معامله ذخیره می شود ، پس این یک مکان اصلی برای نگاه کردن استبرای خطرات اطلاعاتی که ممکن است ناشی از داده های استاد معیوب باشد.

ACTION TIP

اگر فهمیدید که تنها منبع اصلی داده ها در سوابق معامله ذخیره می شود ، این مکان اصلی برای جستجوی خطرات اطلاعاتی است که ممکن است از داده های مسترن بد بوجود بیاید.

بیشتر بخوانید URL: https://www. scienceirect.com/science/article/pii/b978012405476000122

نمای کلی از حسابرسی

سوالات متداول

تفاوت بین سوابق کارشناسی ارشد و داده های معامله ای چیست؟

سوابق کارشناسی ارشد حاوی اطلاعات مربوط به یک شریک تجاری یا مطالب است. تنظیمات ساخته شده در محرک کارشناسی ارشد نحوه پردازش معاملات در SAP. داده های معامله ای داده هایی است که از پردازش معاملات تجاری در سیستم ایجاد می شود.

آیا گزارشی وجود دارد که نشان می دهد سوابق مستر فروشنده را ایجاد و تغییر داده است؟

از گزارش کد معامله S_ALR_87012089 استفاده کنید - برای مشاهده تغییرات در سوابق کارشناسی ارشد فروشنده ، به فروشندگان تغییر دهید.

آیا گزارشی وجود دارد که نشان می دهد سوابق اصلی مشتری را ایجاد و تغییر داده است؟

از گزارش کد تراکنش S_ALR_87012182 - نمایش تغییرات به مشتریان برای مشاهده تغییرات سوابق اصلی مشتری استفاده کنید.

آیا گزارشی وجود دارد که نشان دهد چه کسی رکوردهای اصلی دفتر کل را ایجاد و تغییر داده است؟

از گزارش کد تراکنش S_ALR_87012308 - نمایش تغییرات در حساب های G/L برای مشاهده تغییرات در سوابق اصلی دفتر کل استفاده کنید.

چرخه درآمد شامل چه مواردی است؟

The basic steps in the Revenue cycle are: Sales Order> Pick, Pack, and Ship> Customer Invoice-Billing>پرداخت مشتری

چرخه هزینه شامل چه مواردی می شود؟

The basic steps in the Expenditure cycle are: Purchase Order> Goods Receipt> Invoice Verification>پرداخت به فروشنده

آیا درخت گزارشی وجود دارد که گزارش های مربوط به امنیت را نشان دهد؟

گزارش های مربوط به امنیت در کد تراکنش SUIM قرار دارند.

چه جدولی را می توانم مشاهده کنم تا ببینم چه کسی تغییرات پیکربندی را ایجاد کرده است که به Production منتقل شده است؟

این داده ها در جدول E070 ثبت شده است.

IMG چیست؟

IMG راهنمای پیاده سازی برای سفارشی سازی SAP R/3 است. مراحل پیکربندی مورد نیاز برای پیاده سازی SAP R/3 را فهرست می کند.

AIS در سیستم اطلاعات حسابرسی SAP.[در پیاده سازی های قدیمی SAP، یک درخت گزارش در کد تراکنش SECR است که گزارش های حسابرسی SAP را فهرست می کند. در نسخه های جدیدتر، پروفایل های امنیتی ارائه شده توسط SAP هستند که شامل گزارش های ممیزی می شوند.]

بیشتر بخوانید آدرس اینترنتی: https://www. sciencedirect.com/science/article/pii/B9781597492843000077

بازیابی تصادف: مفهوم درستی

Gerhard Weikum , Gottfried Vossen , در سیستم های اطلاعات تراکنش , 2002

12. 3 مدل سیستم

این بخش، معماری سیستمی را که در بخش قبل معرفی کردیم، به تعاریف دقیق تری تبدیل می کند، که سپس به عنوان مبنایی برای استدلال درستی در سراسر فصل 13 استفاده می شود. از آنجایی که هدف ما نشان دادن این است که پایگاه داده بازیابی شده دقیقاً اثرات تمام به روزرسانی های متعهد را در ترتیب سریال سازی تراکنش های اجرا شده حفظ می کند، تاریخچه سیستم یک نقطه مرجع مهم برای صحت بازیابی است. در مقایسه با فصل های قبلی، در تعریف تاریخچه سیستم به برخی افزودنی ها نیاز داریم. به طور خاص، اقدامات ذخیره سازی برای بازیابی جالب هستند و بنابراین در تاریخچه گنجانده می شوند.

تاریخچه سیستم توسعه یافته یک سرور داده تراکنشی یک جنگل منظم از اقدامات است که مجموعه ای از اقدامات با A نشان داده شده است، جایی که

ریشه ها شناسه های تراکنش یا اقدامات ذخیره سازی (واکشی یا فلاش) هستند.

برگه ها عبارتند از خواندن، نوشتن، یا نوشتن کامل اقدامات یا اقدامات تراکنش (شروع، ارتکاب، بازگشت، ...).

فقط اقدامات exec می توانند به عنوان گره های میانی ظاهر شوند.

ترتیب اعمال که با j نشان داده می شود، رابطه i

تخصصی که ابتدا در نظر خواهیم گرفت ، مدل برای مدل صفحه است که با عدم وجود گره های EXEC مشخص می شود. سپس ، یک تاریخ گسترده به جنگلی تخصص دارد که همه درختان دارای عمق 2 هستند. در بقیه فصل ما همیشه تاریخ های گسترده را به جای تاریخ های "ساده" در نظر می گیریم. بنابراین ، نیازی به تشخیص دو مفهوم صریح نیست ، و از این پس ما به تاریخچه های گسترده صرفاً به عنوان تاریخ اشاره خواهیم کرد.

از آنجا که گزارش پایدار سوابق حسابداری را در مورد تاریخ سیستم نگه می دارد ، می توان آن را با رابطه آن با تاریخ گسترده به شرح زیر تعریف کرد:

برای یک تاریخچه خاص سیستم ، ورود به سیستم پایدار یک زیر مجموعه کاملاً سفارش داده شده از مجموعه اقدامات تاریخ است به گونه ای که سفارش ورود به سیستم با نظم تاریخ سازگار است (یعنی ، متناقض نیست<). These logged actions are referred to as log entries.

همانطور که قبلاً ذکر شد ، ورود به سیستم ممکن است حاوی اطلاعاتی برای خنثیسازی و بازسازی یک عمل به روزرسانی باشد ، زیرا نتیجه معامله مربوطه معمولاً در زمان ایجاد ورود ورود به سیستم هنوز ناشناخته است. با این حال ، در مدل انتزاعی ، ما به صراحت بخش های خنثیسازی و مجدداً ورود به سیستم را متمایز نمی کنیم. در عوض ، ما با عمل وارد شده به عنوان اطلاعات مجدد رفتار می کنیم و فرض می کنیم که همیشه می توانیم از ورود به سیستم یک اقدام معکوس ، به معنای فصل 11 ، که به عنوان اطلاعات خنثیسازی عمل اصلی است ، استنباط کنیم. با این حال ، باید در نظر داشته باشیم که اجرای ورودی های ورود به سیستم نیاز به جزئیات اضافی دارد. به عنوان مثال ، پارامترهای ورودی یک عمل معکوس ممکن است به پارامترهای نتیجه عمل اصلی بستگی داشته باشد و باید به صراحت در ورود به Thelog به یاد داشته باشید.

بنابراین ، ورود به سیستم در اصل خطی سازی تاریخ سیستم است. ما فرض می کنیم که تمام اقدامات ثبت شده اطلاعات کافی برای شناسایی اجداد خود در تاریخ دارند. به طور خاص ، تمام ورودی های ورود به سیستم دارای یک شناسه معامله هستند. بیشتر الگوریتم های بازیابی ، ورودی های ورود به سیستم را به انواع خاصی از اقدامات محدود می کنند ، همانطور که بعداً با جزئیات خواهیم دید. به طور خاص ، تقریباً همه الگوریتم ها از ورود به سیستم از خواندن جلوگیری می کنند.

اکنون می توان بافر ورود به سیستم را به سادگی به عنوان "دم" تاریخ (یا در واقع ، قسمت ورود به سیستم) تعریف کرد که جدیدترین اقدامات را که هنوز در گزارش پایدار ثبت نشده اند ، ضبط می کند.

برای یک تاریخچه سیستم معین، بافر گزارش زیرمجموعه ای کاملاً مرتب از مجموعه اقدامات تاریخچه است به طوری که ترتیب گزارش با ترتیب تاریخچه سازگار است و همه ورودی های بافر گزارش از همه ورودی ها (با توجه به ترتیب کل) پیروی می کنند. گزارش پایدار برای آن تاریخ

در نهایت، در مورد پایگاه داده پایدار و برای پایگاه داده ذخیره شده، یک ملاحظه مهم این است که ما نیازی به رسمیت بخشیدن به تمام جنبه های سازمان داده خود نداریم. در عوض، تمرکز ما روی ردیابی به روزرسانی هایی است که در پایگاه داده وجود دارد یا وجود ندارد، چگونه این به روزرسانی ها با اقدامات ثبت شده مرتبط هستند و چگونه بازیابی وضعیت پایگاه داده را ارتقا می دهد. برای این منظور، مناسب است که وضعیت یک پایگاه داده را نیز به عنوان مجموعه ای از اقدامات به روز رسانی، یعنی آن دسته از اقداماتی که به وضعیت منتهی شده اند، مشاهده کنیم.

بدیهی است که وضعیت حاصل بستگی به ترتیب انجام اقدامات در پایگاه داده دارد. بنابراین باید دانشی در مورد ترتیب عمل در تعریف رسمی خود لحاظ کنیم. برای سازگاری با ملاحظات عملی، باید در نظر بگیریم که ترتیب دقیق به روزرسانی ها را نمی توان به تنهایی از یک پایگاه داده مشخص استنباط کرد. با این حال، با گنجاندن اطلاعات اضافی در خود پایگاه داده، می توانیم اطلاعاتی جزئی از سفارش کسب کنیم. برای این منظور، فرض می کنیم که هر صفحه پایگاه داده با یک شماره دنباله برچسب گذاری شده است، که به وسیله آن می توانیم آخرین اقدام از انواع خاصی را که در آن صفحه اجرا شده اند، پیگیری کنیم. فرض بر این است که این شماره دنباله صفحه یا شناسه وضعیت صفحه در خود صفحه تعبیه شده است. بنابراین، زمانی که یک صفحه به کش پایگاه داده واکشی می شود یا از کش به پایگاه داده پایدار بازگردانده می شود، همیشه همراه است. وجود چنین شماره ترتیب صفحه فرض خاصی است که ما می کنیم، اما توجه داشته باشید که کاملاً مطابق با تمام سیستم های پیاده سازی شده ای است که از آن آگاه هستیم. در واقع، شماره های دنباله صفحه را می توان به راحتی با سربار بسیار کمی به عنوان یک فیلد در هدر صفحه پیاده سازی کرد. این را با مفروضات قابل تصور در مورد برچسب گذاری تمام رکوردهای داده با یک شماره دنباله یا شناسه تراکنش مقایسه کنید، که اجرای آنها اصلاً واضح نیست و احتمالاً هزینه بالایی را متحمل می شود.

شماره های توالی صفحه به عنوان شناسه های حالت

نکته اصلی شماره دنباله صفحه این است که می تواند دانش جزئی در مورد ترتیب اقدامات نوشتن (از جمله اقدامات کامل نوشتاری) که روی آن انجام شده است ، به ما دانش جزئی بدهد. یعنی ، برای یک صفحه با شماره دنباله S ، ما می دانیم که تمام اقدامات نوشتن در آن صفحه با شماره دنباله ای کمتر از S باید قبل از عمل نوشتن با شماره دنباله S در ترتیب تاریخ باشد<. We still do not have any knowledge about the ordering among those earlier actions, but we will see that this knowledge is not necessary for a recovery algorithm anyway.

این ملاحظات به ترتیب به تعاریف زیر از پایگاه داده های ذخیره شده و پایدار منجر می شود. تنها تفاوت بین این دو در این است که تعداد دنباله صفحه پایگاه داده ذخیره شده با جدیدترین اقدامات نوشتن در تاریخ مطابقت دارد. در حالی که در پایگاه داده پایدار ، تعداد دنباله یک صفحه قبل از جدیدترین اقدام Flush برای آن صفحه با جدیدترین اقدام نوشتن مطابقت دارد.

برای یک تاریخچه خاص سیستم ، پایگاه داده ذخیره شده مجموعه ای از همه اقدامات نوشتن در تاریخ ، از جمله اقدامات کامل نوشتن ، به گونه ای است که سفارش زیر مجموعه ای از ترتیب تاریخ است و برای هر صفحه P ، حداکثر عنصراز جمله اقدامات نوشتن در مورد P در تاریخ نیز حداکثر عنصر در بین کلیه اقدامات نوشتن در P در پایگاه داده ذخیره شده است.

برای یک تاریخچه سیستم خاص ، پایگاه داده پایدار یک زیر مجموعه جزئی از اقدامات نوشتن تاریخ است ، از جمله اقدامات کامل نوشتاری ، به گونه ای که سفارش زیر مجموعه ای از ترتیب تاریخ و برای هر شماره صفحه P است.

تمام اقدامات نوشتن در P که پیش از جدیدترین اقدامات Flush (P) در تاریخ است ، در پایگاه داده پایدار گنجانده شده است ،

حداکثر عنصر در بین همه اقدامات نوشتن در تاریخ نیز حداکثر عنصر در بین تمام اقدامات نوشتن در P در پایگاه داده پایدار است.

این تعاریف با ریخته گری کلیه مؤلفه های سیستم در مجموعه های اقدامات جزئی سفارش داده شده ، به ما امکان می دهد تا پایگاه داده پایدار را با ورود به سیستم پایدار و ورود به سیستم پایدار به نوبه خود به تاریخ سیستم مرتبط و مقایسه کنیم. این روابط متقاطع ما را به سمت معیار صحت توسعه یافته در بخش زیر سوق می دهد.

بیشتر بخوانید URL: https://www. scienceirect.com/science/article/pii/b9781558605084500132

تجزیه و تحلیل الزامات داده

خلاصه ناشر

این فصل ابتدا یک چرخه با فضیلت را مورد بحث قرار می دهد ، که در آن از داده های عملیاتی و معامله ای برای تجزیه و تحلیل تجارت استفاده می شود ، که نتایج آن برای بهبود فرآیندهای تجاری به همان سیستم های عملیاتی بازگردانده می شود. مقدمه ای برای تجزیه و تحلیل الزامات داده ها ارائه شده و با قدم زدن از طریق فرآیندی که می تواند برای ارزیابی چگونگی استفاده از برنامه های تجزیه و تحلیل پایین دست از داده ها و چگونگی شناسایی و به اشتراک گذاری نیازهای آنها با برنامه های تولیدکننده بالادست ارائه شده باشد ، ارائه شده است. انواع قوانین کیفیت داده که می تواند در نتیجه فرآیند تجزیه و تحلیل الزامات تعریف شود ، می تواند برای تهیه مجموعه ای از قوانین اعتبار سنجی استفاده شود که نه تنها برای نظارت فعال و ایجاد توافق نامه سطح خدمات کیفیت داده قابل استفاده است ، بلکه می تواند باشد. هنگامی که انتظار می رود از برنامه در پایین دست استفاده شود ، مستقیماً در هر برنامه تازه توسعه یافته ادغام می شود. ادغام این روش تجزیه و تحلیل الزامات داده در چرخه زندگی توسعه سیستم سازمان (SDLC) منجر به بهبود کنترل بر روی ابزار و کیفیت دارایی های داده سازمانی خواهد شد. قوانین کیفیت داده ، که در متن ابعاد کیفیت داده ها تعریف شده است ، در این فصل بررسی شده است.

بیشتر بخوانید URL: https://www. scienceirect.com/science/article/pii/b9780123737175000099

ادغام داده های بزرگ و انبارداری داده ها

طبقه بندی داده ها

همانطور که در شکل 10. 3 نشان داده شده است ، طبقه بندی گسترده داده ها وجود دارد:

داده های معامله ای - داده های کلاسیک OLTP متعلق به این بخش است.

داده های برنامه وب - داده های برنامه های وب که توسط سازمان تهیه شده اند می توانند به این گروه اضافه شوند. این داده ها شامل داده های ClickStream ، داده های تجارت وب و ارتباط با مشتری و داده های چت مرکز تماس است.

DATA EDW - این داده های موجود از انبار داده است که در حال حاضر توسط سازمان استفاده می شود. این می تواند شامل کلیه انبارهای مختلف داده ها و داده های مختلف در سازمان باشد که داده ها برای استفاده توسط کاربران تجاری پردازش و ذخیره می شوند.

داده های تحلیلی - این داده های سیستم های تحلیلی است که در حال حاضر در سازمان مستقر شده اند. داده های امروز در درجه اول مبتنی بر داده های EDW یا معامله است.

داده های بدون ساختار - زیر این گروه گسترده ، می توانیم شامل موارد زیر شویم.

متن - مجموعه ها ، یادداشت ها ، یادداشت ها ، قراردادها.

تصاویر - عکس ها ، نمودارها ، نمودارها.

فیلم ها - فیلم های عضو و مصرف کننده مرتبط با سازمان.

رسانه های اجتماعی - کتاب ، توییتر ، اینستاگرام ، لینکدین ، انجمن ها ، یوتیوب ، وب سایت های جامعه.

AUDIO - مکالمات مرکز ، پخش.

داده های سنسور - از جمله داده های سنسورهای موجود در هر یا تمام دستگاه هایی که مربوط به خط تجارت سازمان هستند. به عنوان مثال ، داده های Smart Meter یک دارایی تجاری را برای یک شرکت انرژی ایجاد می کند و سنسورهای کامیون و اتومبیل مربوط به تدارکات و ارائه دهندگان حمل و نقل مانند UPS و FedEx هستند.

داده های آب و هوا - امروزه توسط هر دو مشاغل B2B و B2C برای تجزیه و تحلیل تأثیر آب و هوا بر تجارت استفاده می شود. به یک مؤلفه حیاتی تجزیه و تحلیل پیش بینی تبدیل شده است.

داده های علمی-این داده ها در مورد بخش های پزشکی ، دارویی ، بیمه ، مراقبت های بهداشتی و خدمات مالی اعمال می شود که در آن تعداد زیادی از نوع محاسبات از جمله شبیه سازی ها و تولید مدل انجام می شود.

داده های بازار سهام - برای پردازش داده های مالی در بسیاری از سازمانها برای پیش بینی روند بازار ، ریسک مالی و محاسبات محرک استفاده می شود.

داده های نیمه ساختار یافته-این شامل ایمیل ، ارائه ، مدل ها و نمودارهای ریاضی و داده های جغرافیایی است.

بیشتر بخوانید URL: https://www. scienceirect.com/science/article/pii/b9780124058910000106

انتشارات توصیه شده

نماد اطلاعات مجله مجله مجله مجله

معدن الگوی پیشرفته

جیاوی هان ،. جیان پی ، در داده کاوی (چاپ سوم) ، 2012

7. 2. 1 انجمن های چند سطحی معدن

برای بسیاری از برنامه ها ، انجمن های قوی کشف شده در سطح انتزاع بالا ، هرچند با حمایت بالا ، می توانند دانش متمایز باشند. ما ممکن است بخواهیم برای یافتن الگوهای جدید در سطوح دقیق تر ، حفر کنیم. از طرف دیگر ، می توان بسیاری از الگوهای پراکنده در سطح انتزاع کم یا ابتدایی وجود داشت که برخی از آنها فقط تخصص های بی اهمیت الگوهای در سطوح بالاتر هستند. بنابراین ، جالب است که چگونه می توان روشهای مؤثر برای الگوهای معدن را در سطوح مختلف انتزاع ایجاد کرد ، با انعطاف پذیری کافی برای عبور آسان در بین فضاهای مختلف انتزاع.

مثال 7. 1

قوانین انجمن چند سطحی معدن

فرض کنید به ما مجموعه داده های مربوط به معامله در جدول 7. 1 برای فروش در یک فروشگاه Allelectronics داده می شود و موارد خریداری شده برای هر معامله را نشان می دهد. سلسله مراتب مفهوم برای موارد در شکل 7. 2 نشان داده شده است. یک سلسله مراتب مفهومی دنباله ای از نقشه ها را از مجموعه ای از مفاهیم سطح پایین به یک مجموعه مفهوم سطح بالاتر و عمومی تر تعریف می کند. داده ها را می توان با جایگزین کردن مفاهیم سطح پایین در داخل داده ها با مفاهیم سطح بالاتر یا اجداد مربوط به آنها از یک سلسله مراتب مفهومی تعمیم داد.

جدول 7. 1. داده های مربوط به کار ، د

شکل 7. 2 سلسله مراتب مفهوم دارای پنج سطح است که به ترتیب به عنوان سطح 0 تا 4 گفته می شود ، از سطح 0 در گره ریشه برای همه (عمومی ترین سطح انتزاع) شروع می شود. در اینجا ، سطح 1 شامل رایانه ، نرم افزار ، چاپگر و دوربین و لوازم جانبی رایانه است. سطح 2 شامل رایانه لپ تاپ ، رایانه رومیزی ، نرم افزار اداری ، نرم افزار آنتی ویروس و غیره است. و سطح 3 شامل رایانه رومیزی Dell ،… ، نرم افزار Microsoft Office و غیره است. سطح 4 خاص ترین سطح انتزاع این سلسله مراتب است. این از مقادیر داده خام تشکیل شده است.

سلسله مراتب مفهومی برای ویژگی های اسمی اغلب در طرح پایگاه داده ضمنی هستند ، در این صورت ممکن است به طور خودکار با استفاده از روش هایی مانند مواردی که در فصل 3 شرح داده شده است تولید شود. برای مثال ما ، سلسله مراتب مفهوم شکل 7. 2 از داده های مربوط به مشخصات محصول تولید شده است. سلسله مراتب مفهومی برای ویژگی های عددی را می توان با استفاده از تکنیک های گسسته سازی تولید کرد که بسیاری از آنها در فصل 3 معرفی شده اند. از طرف دیگر ، سلسله مراتب مفهوم ممکن است توسط کاربران آشنا با داده هایی مانند مدیران فروشگاه در مورد مثال ما مشخص شود.

موارد موجود در جدول 7. 1 در پایین ترین سطح سلسله مراتب مفهوم شکل 7. 2 قرار دارد. یافتن الگوهای خرید جالب در چنین داده های سطح خام یا ابتدایی دشوار است. به عنوان مثال ، اگر "Dell Studio XPS 16 Notebook" یا "Logitech VX Nano Cordless Mouse" در بخش بسیار کمی از معاملات رخ دهد ، می توان پیدا کردن انجمن های قوی مربوط به این موارد خاص را دشوار کرد. ممکن است تعداد کمی از افراد این موارد را با هم خریداری کنند ، بعید به نظر می رسد که این مورد حداقل پشتیبانی را برآورده کند. با این حال ، ما انتظار داریم که یافتن ارتباطات قوی بین انتزاع های عمومی این موارد ، مانند "نوت بوک دل" و "موش بی سیم" آسان تر باشد.

قوانین انجمن تولید شده از داده های استخراج شده در سطوح مختلف انتزاع ، قوانین ارتباطی چند سطح یا چند سطحی نامیده می شوند. قوانین انجمن چند سطحی را می توان با استفاده از سلسله مراتب مفهوم تحت یک چارچوب اعتماد به نفس به طور مؤثر استخراج کرد. به طور کلی ، یک استراتژی از بالا به پایین استفاده می شود ، جایی که شمارش برای محاسبه موارد مکرر در هر سطح مفهوم جمع می شود ، از سطح مفهوم شروع می شود و در سلسله مراتب به سمت سطح مفهوم خاص تر کار می کند ، تا زمانی که هیچ موارد مکرر نتواندیافت می شود. برای هر سطح ، ممکن است از هر الگوریتم برای کشف موارد مکرر استفاده شود ، مانند آپریوری یا تغییرات آن.

تعدادی از تغییرات در این روش در مرحله بعدی شرح داده شده است ، جایی که هر تغییر شامل "بازی" با آستانه پشتیبانی به روشی کمی متفاوت است. این تغییرات در شکل 7. 3 و 7. 4 نشان داده شده است ، جایی که گره ها یک مورد یا مورد را نشان می دهند که مورد بررسی قرار گرفته است ، و گره هایی با مرزهای ضخیم نشان می دهد که یک مورد یا مورد مورد بررسی مکرر است.

با استفاده از حداقل پشتیبانی یکنواخت برای تمام سطوح (که به عنوان پشتیبانی یکنواخت گفته می شود): حداقل آستانه پشتیبانی در هنگام استخراج در هر سطح انتزاع استفاده می شود. به عنوان مثال ، در شکل 7. 3 ، حداقل آستانه پشتیبانی 5 ٪ در کل استفاده می شود (به عنوان مثال ، برای استخراج از "رایانه" به سمت پایین به "رایانه لپ تاپ"). هر دو "رایانه" و "رایانه لپ تاپ" مکرر هستند ، در حالی که "رایانه رومیزی" نیست.

هنگامی که از آستانه حداقل پشتیبانی یکنواخت استفاده می شود ، روش جستجو ساده می شود. این روش همچنین ساده است که کاربران برای مشخص کردن فقط یک آستانه پشتیبانی حداقل لازم هستند. با توجه به این دانش که یک جد از فرزندان آن سوپراست است ، می توان یک تکنیک بهینه سازی شبیه به apriori را اتخاذ کرد: جستجو از بررسی موارد حاوی مواردی که اجداد از آنها حداقل پشتیبانی ندارند ، جلوگیری می کند.

با این حال ، رویکرد پشتیبانی یکنواخت اشکالاتی دارد. بعید است که مواردی که در سطح انتزاع پایین تر قرار دارند ، به همان میزان در سطح انتزاع بالاتر اتفاق بیفتد. اگر حداقل آستانه پشتیبانی بیش از حد بالا باشد ، می تواند برخی از ارتباطات معنی دار را که در سطح انتزاع کم اتفاق می افتد از دست بدهد. اگر آستانه خیلی کم تنظیم شود ، ممکن است بسیاری از انجمن های غیرقابل علاقه در سطح انتزاع بالا ایجاد شود. این انگیزه برای رویکرد بعدی را فراهم می کند.

با استفاده از حداقل پشتیبانی از حداقل در سطوح پایین تر (که به عنوان پشتیبانی کاهش یافته گفته می شود): هر سطح انتزاع آستانه پشتیبانی حداقل خود را دارد. هرچه سطح انتزاع عمیق تر باشد ، آستانه مربوطه کوچکتر است. به عنوان مثال ، در شکل 7. 4 ، حداقل آستانه پشتیبانی برای سطح 1 و 2 به ترتیب 5 ٪ و 3 ٪ است. به این ترتیب ، "رایانه" ، "رایانه لپ تاپ" و "رایانه رومیزی" همه مکرر در نظر گرفته می شوند.

با استفاده از حداقل پشتیبانی مورد یا گروهی مبتنی بر گروه (به عنوان پشتیبانی مبتنی بر گروه گفته می شود): از آنجا که کاربران یا کارشناسان اغلب بینش دارند که کدام گروه ها از سایرین مهمتر هستند ، گاهی اوقات تنظیم خاص کاربر ، مورد یا مورد مطلوب تر استآستانه حداقل پشتیبانی مبتنی بر گروه هنگام استخراج قوانین چند سطحی. به عنوان مثال ، یک کاربر می تواند حداقل آستانه های پشتیبانی را بر اساس قیمت محصول یا موارد مورد علاقه تنظیم کند ، مانند تنظیم آستانه های پشتیبانی ویژه برای "دوربین با قیمت بیش از 1000" یا "رایانه لوحی" ، برای توجه ویژه بهالگوهای انجمن حاوی موارد در این دسته ها.

برای الگوهای استخراج معادن با موارد مختلط از گروه هایی با آستانه پشتیبانی مختلف ، معمولاً کمترین آستانه پشتیبانی در بین همه گروه های شرکت کننده به عنوان آستانه پشتیبانی در معدن گرفته می شود. با این کار از فیلتر کردن الگوهای ارزشمند حاوی مواردی از گروه با کمترین آستانه پشتیبانی جلوگیری می شود. در ضمن ، آستانه پشتیبانی حداقل برای هر گروه باید نگه داشته شود تا از تولید موارد غیرقابل علاقه از هر گروه جلوگیری شود. از دیگر اقدامات جالب توجه می توان پس از استخراج آیتم های معدن برای استخراج قوانین واقعاً جالب استفاده کرد.

توجه کنید که خاصیت Apriori ممکن است همیشه در هنگام استخراج تحت حمایت کاهش یافته و پشتیبانی مبتنی بر گروه ، به طور یکنواخت در همه موارد نباشد. با این حال ، روش های کارآمد می توانند بر اساس گسترش خاصیت خاص توسعه یابد. جزئیات به عنوان یک تمرین برای خوانندگان علاقه مند باقی مانده است.

یک عارضه جدی در قوانین انجمن چند سطحی استخراج معادن ، تولید بسیاری از قوانین اضافی در سطح چندین انتزاع به دلیل روابط "اجداد" بین موارد است. به عنوان مثال ، قوانین زیر را در نظر بگیرید که در آن "رایانه لپ تاپ" اجداد "رایانه لپ تاپ Dell" بر اساس سلسله مراتب مفهوم شکل 7. 2 است ، و جایی که X متغیری است که به نمایندگی از مشتریانی است که مواردی را در معاملات Allelectronic خریداری کرده است.

(7. 4) b u y s (x ، "l a p t o p c o m p u t e r") ⇒ b u y s (x ، "h p p r i n t e r") [s u p p o r t = 8 ٪ ، c o n f i d e n c e = 70 ٪]

(7. 5) b u y s (x ، "d e l l l a p t o p c o m p u t e r") ⇒ b u y s (x ، "h p p r i n t e r") [s u p p o r t = 2 ٪ ، c o n f i d e n c e = 72 ٪]

"اگر قوانین (7. 4) و (7. 5) هر دو استخراج شده اند ، پس قانون (7. 5) چقدر مفید است؟آیا واقعاً اطلاعات جدیدی ارائه می دهد؟"اگر دومی ، قانون عمومی کمتری اطلاعات جدیدی را ارائه نمی دهد ، باید آن را حذف کرد. بیایید ببینیم که چگونه ممکن است این تعیین شود. یک قانون R 1 اجداد یک قانون R 2 است ، اگر R 1 را می توان با جایگزینی موارد در R 2 توسط اجداد خود در یک سلسله مراتب مفهومی بدست آورد. به عنوان مثال ، قانون (7. 4) اجداد قانون (7. 5) است زیرا "رایانه لپ تاپ" اجداد "رایانه لپ تاپ دل" است. بر اساس این تعریف ، اگر حمایت و اعتماد به نفس آن نزدیک به ارزشهای "مورد انتظار" آنها باشد ، بر اساس یک جد این قانون ، یک قاعده را می توان در نظر گرفت.

مثال 7. 2

بررسی افزونگی بین قوانین انجمن چند سطحی

فرض کنید که قانون (7. 4) دارای اعتماد به نفس 70 ٪ و 8 ٪ پشتیبانی است و حدود یک چهارم از همه فروش "رایانه لپ تاپ" برای "رایانه های لپ تاپ Dell" است. ما ممکن است انتظار داشته باشیم که قانون (7. 5) اعتماد به نفس حدود 70 ٪ داشته باشد (از آنجا که تمام نمونه های داده "رایانه لپ تاپ Dell" نیز نمونه "رایانه لپ تاپ" هستند) و پشتیبانی از حدود 2 ٪ (یعنی 8 ٪ 1 4 4). اگر واقعاً اینگونه باشد ، قانون (7. 5) جالب نیست زیرا هیچ اطلاعات اضافی ارائه نمی دهد و کمتر از قانون (7. 4) است.