متامدل مکعب داده برای تحلیل جغرافیایی شامل ابعاد ناهمگن

چکیده

با توجه به منابع و ساختارهای متعدد، داده‌های فضایی بزرگ نیازمند ابزارهای مناسب برای جمع‌آوری، خلاصه و تحلیل کارآمد هستند. برای این منظور، داده ها در انبارهای داده بایگانی شده و توسط پردازش تحلیلی آنلاین فضایی (SOLAP) از طریق نقشه ها، نمودارها و جداول پویا مورد بررسی قرار می گیرند. بنابراین داده ها در مکعب های داده تبدیل می شوند که با ساختاری چند بعدی که کاوش بر آن استوار است مشخص می شود. با این حال، منابع متعدد اغلب به چندین مکعب داده منجر می‌شوند که با ابعاد ناهمگن تعریف شده‌اند. به طور خاص، تعریف ابعاد می تواند بسته به مقیاس، قلمرو و زمان تحلیل شده تغییر کند. به منظور در نظر گرفتن این سه موضوع خاص برای تجزیه و تحلیل جغرافیایی، این تحقیق یک متامدل مکعب داده اصلی تعریف شده در زبان مدل‌سازی یکپارچه (UML) را پیشنهاد می‌کند. بر اساس مفاهیمی مانند سطوح بعدی و فراابعاد مشترک، این متامدل می‌تواند صور فلکی از مکعب‌های داده ناهمگن را نشان دهد که به SOLAP اجازه می‌دهد تحلیل چند مقیاسی، چند منطقه‌ای و زمانی را انجام دهد. پس از آن، متامدل در یک انبار داده رابطه ای پیاده سازی شده و توسط یک ابزار عملیاتی طراحی شده برای مطالعه موردی اقتصاد اجتماعی اعتبار سنجی می شود. این ابزار که “راسینز” نام دارد، داده های چند بعدی را در مورد تجارت اقتصاد اجتماعی در بلژیک و فرانسه از طریق نقشه ها، نمودارها و گزارش های تعاملی فرامرزی جمع آوری و مقایسه می کند. به لطف متامدل، کاربران در مورد کاوش و یکپارچه سازی داده ها از متخصصان فناوری اطلاعات مستقل باقی می مانند. متامدل در یک انبار داده رابطه ای پیاده سازی شده و توسط یک ابزار عملیاتی طراحی شده برای مطالعه موردی اقتصاد اجتماعی تایید شده است. این ابزار که “راسینز” نام دارد، داده های چند بعدی را در مورد تجارت اقتصاد اجتماعی در بلژیک و فرانسه از طریق نقشه ها، نمودارها و گزارش های تعاملی فرامرزی جمع آوری و مقایسه می کند. به لطف متامدل، کاربران در مورد کاوش و یکپارچه سازی داده ها از متخصصان فناوری اطلاعات مستقل باقی می مانند. متامدل در یک انبار داده رابطه ای پیاده سازی شده و توسط یک ابزار عملیاتی طراحی شده برای مطالعه موردی اقتصاد اجتماعی تایید شده است. این ابزار که “راسینز” نام دارد، داده های چند بعدی را در مورد تجارت اقتصاد اجتماعی در بلژیک و فرانسه از طریق نقشه ها، نمودارها و گزارش های تعاملی فرامرزی جمع آوری و مقایسه می کند. به لطف متامدل، کاربران در مورد کاوش و یکپارچه سازی داده ها از متخصصان فناوری اطلاعات مستقل باقی می مانند.

کلید واژه ها:

انبار داده ; هوش تجاری ؛ OLAP ; SOLAP ; GIS

1. مقدمه

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

از یک سو، ساختارهای داده ناهمگن منجر به ایجاد پنل بزرگی از فناوری‌ها برای مدیریت آنها شده است: پایگاه‌های داده رابطه‌ای، ذخیره‌سازی اسناد، نمودارها، مکعب‌های داده، دریاچه‌های داده و غیره. از سوی دیگر، ابزارهای قدرتمند امکان جمع‌آوری و تجزیه و تحلیل داده ها به منظور ایجاد اطلاعات ارزشمند. تجزیه و تحلیل کلان داده ها را می توان توسط ماشین ها در زمینه های امیدوار کننده مانند هوش مصنوعی، یادگیری ماشین، یادگیری عمیق و غیره انجام داد. برخلاف ماشین‌ها، انسان‌ها برای تصمیم‌گیری به نمایش خلاصه‌ای از داده‌ها نیاز دارند. این جنبه که این تحقیق بر آن استوار است، هوش تجاری (BI) نامیده می شود. برای تبدیل ساختارهای داده به ابزارهای «Extract, Transform, Load» (ETL) نیاز دارد.

در میان داده های بزرگ، حدود 80 درصد دارای یک جزء فضایی هستند [ 1]. این دری را به روی تحلیل جغرافیایی و مسائل خاص مربوط به داده های ناهمگن باز می کند. ما سه تا از آنها را شناسایی می کنیم. اول، یک اصل اصلی جغرافیا، تجزیه و تحلیل چند مقیاسی است. در واقع، یک پدیده فضایی باید در مقیاس های مختلف برای درک جهانی آن تحلیل شود (به عنوان مثال، خیابان، منطقه، شهر، منطقه، کشور). با این حال، داده های موجود بسته به سطح تجمیع آنها می تواند کم و بیش جزئی باشد. به عنوان مثال، داده های اقتصاد فرانسه که تعداد کارگران در هر اندازه شرکت را نشان می دهد، در مقیاس بخش در دسترس است اما در مقیاس کمون به دلیل محرمانه بودن آماری موجود نیست. ثانیاً، مقایسه سرزمین‌ها می‌تواند با تعاریف داده‌های متفاوت در این قلمروها مغرضانه باشد. به عنوان مثال، دسته بندی شرکت ها از نظر حوزه فعالیت در فرانسه و بلژیک متفاوت است. در نهایت، جغرافیا همچنین شامل تجزیه و تحلیل زمانی است که در معرض تغییرات در ابعاد داده است. به عنوان مثال، تعداد کمون های بلژیک از 589 به 581 به دلیل ادغام اداری در سال 2019 کاهش یافت.

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

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

ساختار مقاله به شرح زیر است. در بخش 2 ، ادبیات مربوط به تجزیه و تحلیل جغرافیای اقتصادی، BI و OLAP را بررسی می کنیم. بخش 3 ادبیات مربوط به متامدل های OLAP و سه موضوع خاص تحلیل جغرافیایی را بررسی می کند: تجزیه و تحلیل چند مقیاسی، تجزیه و تحلیل چند منطقه ای و تحلیل زمانی. در بخش 4 ، ما به طور خلاصه مطالعه موردی اقتصاد اجتماعی خود را ارائه می کنیم و فرضیه تحقیق خود را فرموله می کنیم. در بخش 5 ، ما متامدل اصلی خود را به دنبال اجرای رابطه ای آن در بخش 6 ارائه می کنیم. در بخش 7، این متامدل توسط پلتفرم وب BI که به یکپارچه سازی و تجزیه و تحلیل جغرافیایی داده های چند بعدی در مورد شرکت ها و کارگران اقتصاد اجتماعی اختصاص داده شده است تأیید شده است. در نهایت، این مقاله را در بخش 8 به پایان می‌رسانیم .

2. پس زمینه

این بخش به بررسی ادبیات مرتبط با هدف تحقیق ما اختصاص دارد. با مفاهیم اصلی تحلیل جغرافیای اقتصادی شروع می شود زیرا ابزار ما برای این منظور طراحی شده است ( بخش 2.1 ). بخش 2.2 ، بخش 2.3 ، بخش 2.4 و بخش 2.5 به OLAP در مورد زیرساخت‌های BI، OLAP فضایی (SOLAP)، پیاده‌سازی OLAP و مدل‌سازی OLAP اختصاص دارد.

2.1. تحلیل جغرافیای اقتصادی

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

یک بحث اساسی در جغرافیای اقتصادی این است که آیا مکان‌ها با رقابت شرکت‌ها مرتبط‌تر هستند یا اینکه شبکه‌ها اهمیت بیشتری دارند [ 2 ]. مفهوم «فضای مکان‌ها» بیانگر این ایده است که مکان برای یادگیری و نوآوری مهم است، در حالی که شبکه‌ها ابزارهای مهم انتقال و انتشار دانش هستند [ 3 ]. با این حال، این بحث تا همین اواخر یک موضوع واقعی در ادبیات مربوط به خوشه های نوآوری نبود. شبکه ها با تنظیمات بین شرکتی مرتبط هستند که در آن ایجاد، انتشار و نوآوری دانش صورت می گیرد [ 4 ]]. این ایده‌ها با تمرکز بر اقدام اقتصادی به شیوه‌ای رابطه‌ای و پویا در زمینه‌های تحقیقاتی متعدد در جغرافیای اقتصادی طنین‌انداز می‌شوند. این شامل جغرافیای عمل [ 5 ]، جغرافیای اقتصادی تکاملی [ 6 ] و جغرافیای اقتصادی رابطه ای [ 7 ] است. ابزار توسعه یافته در این تحقیق به نیازهای یک پروژه (VISES یا “Valorisation de l’Impact Social de l’Entrepreneuriat Social”، به بخش 4.1 مراجعه کنید ) با روشی مشابه پاسخ می دهد. مجموعه داده های مختلف در مورد شرکت های اقتصاد اجتماعی برای مطالعه سهم آنها در پویایی سرزمینی جمع آوری شده است.

2.2. هوش تجاری و پردازش تحلیلی آنلاین (OLAP)

هوش تجاری (BI) به مجموعه ای از ابزارها برای کاوش و تجزیه و تحلیل مجموعه داده های بزرگ اشاره دارد [ 8 ]. همانطور که در شکل 1 نشان داده شده است ، یک زیرساخت BI معمولی شامل منابع داده ناهمگن است که از طریق سیستم های ETL به یک انبار داده متصل می شوند [ 9 ]. ETL امکان خودکارسازی تبدیل داده ها را به یک ساختار چند بعدی می دهد که الگوی رایج مورد استفاده برای کاوش و تجزیه و تحلیل داده ها است. در واقع، داده‌های بزرگ با حجم، تنوع و پیچیدگی مهم مشخص می‌شوند که به ابزارهای مناسب برای جمع‌آوری و ذخیره‌سازی نیاز دارند [ 10 ].

یک انبار داده (DW) داده های چند بعدی را با پیروی از رویکرد OLAP آرشیو می کند [ 11 ، 12 ]. برخلاف پردازش تراکنش آنلاین (OLTP)، OLAP شامل فرآیندهای تجمیع پیچیده اما سریع به منظور خلاصه کردن داده ها در جداول یا نمودارها است. این جنبه احتمالاً می‌تواند با ذخیره نسخه‌های مختلف یک مجموعه داده در سطوح مختلف تجمیع سلسله مراتب بعدی (مانند داده در سال، داده در ماه، داده در هفته و غیره) مدیریت شود. این افزونگی بر ثبات سیستم تأثیر نمی گذارد زیرا OLAP فقط داده ها را به موقع بایگانی می کند و هرگز به به روز رسانی نیاز ندارد. در واقع، فقط داده های جدید را می توان در یک DW درج کرد و قرار نیست داده های آرشیو شده تکامل یابند.

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

به ترتیب تخصیص ابعاد به سطرها و ستون های جدول محوری [ 13 ].
تخصیص اندازه گیری به سلول های جدول محوری؛
در یک سلسله مراتب بُعد (مثلاً جابجایی بین سطوح «سال» و «ماه» یک بعد زمانی) و در نتیجه معیارهای انبوه را جمع آوری کنید .
یک بعد را برش دهید (به عنوان مثال، فقط معیارهای پیوست شده به ماه “نوامبر 2020” بعد زمانی را در نظر بگیرید).

علاوه بر اکتشاف رایگان، سیستم‌های OLAP می‌توانند ابزارهای گزارش‌دهی را نیز فراهم کنند. اینها خروجی های ثابت مانند فایل های pdf («قالب سند قابل حمل») یا داشبوردهای وب هستند که نمایش داده های از پیش محاسبه شده خاصی را نشان می دهند. به عنوان مثال، یک گزارش می تواند شامل نموداری باشد که فروش را بر اساس هفته و نوع محصول نشان می دهد که به طور خودکار هر هفته به روز می شود (زمانی که داده های جدید در DW بایگانی می شوند). پتانسیل تحلیلی نسبت به کاوش رایگان OLAP قدرت کمتری دارد اما مستقیماً روندهای مهم داده ها را بدون نیاز به هیچ اقدامی از کاربر نهایی نشان می دهد. در واقع، کاوش بدون داده گاهی اوقات می تواند برای کاربران ناآگاه گیج کننده باشد، به خصوص زمانی که ابعاد داده ها متعدد است [ 14 ].

2.3. پردازش تحلیلی آنلاین فضایی (SOLAP)

OLAP فضایی (SOLAP) فضایی سازی مفاهیم OLAP را برای اهداف تحلیل جغرافیایی معرفی می کند [ 15 ]. بنابراین، یک مکعب داده‌های مکانی می‌تواند شامل ابعاد فضایی باشد که عناصر آن (اعضا) با یک تعریف فضایی مانند مختصات موجودیت‌های برداری مشخص می‌شوند [ 16 ]. به عنوان مثال، یک بعد فضایی می تواند شامل نهادهای اداری مانند کشورهای مرتبط با چند ضلعی های جغرافیایی باشد. ابعاد فضایی به نمایش داده ها در نقشه های تعاملی و همچنین عملیات SOLAP مانند حفاری فضایی در سلسله مراتب ابعاد فضایی اجازه می دهد (مثالی در بخش 5.1 آورده شده است.، شکل 8). بنابراین، تجزیه و تحلیل چند مقیاسی و مقایسه قلمروها می تواند به طور موثر توسط SOLAP برای داده های همگن مدیریت شود. علاوه بر این، SOLAP می تواند از تحلیل چند بعدی ارائه شده توسط OLAP و تحلیل فضایی ارائه شده توسط GIS بهره مند شود. این منجر به عملیات SOLAP اصلی مانند OLAP-buffer یا OLAP-overlay می شود که در [ 17 ، 18 ] شرح داده شده است. این تحقیق همچنین اصطلاح «بعد جغرافیایی» را به جای «بعد فضایی» پیشنهاد می‌کند، زیرا این اعضای بعد هم شامل یک تعریف معنایی (به عنوان مثال، کشور بلژیک) و هم یک تعریف فضایی (به عنوان مثال، یک چند ضلعی که مرز بلژیک را نشان می‌دهد) است. ادامه این مقاله از این گزاره پیروی می کند.

SOLAP می تواند در حوزه های مختلفی مانند تجزیه و تحلیل آلاینده [ 17 ]، تجزیه و تحلیل جرم [ 19 ]، تجزیه و تحلیل خطر [ 20 ]، تحرک [ 21 ]، جنگلداری [ 22 ]، مراقبت های بهداشتی [ 23 ]، اپیدمیولوژی [ 24 ] و غیره مفید باشد. برخی از دامنه ها می توانند به مدل های SOLAP اقتباس شده نیاز داشته باشند تا با نیازهای برنامه مطابقت داشته باشند. به عنوان مثال، ارتباط معمول موجودیت های محدود بردار با ابعاد جغرافیایی برای حوزه هایی که نیاز به دید پیوسته از فضا (میدان) دارند، سازگار نیست [ 25 ]. برای این منظور، یک تعریف جایگزین از ابعاد فضایی در [ 19 ] ارائه شده است]: ابعاد جغرافیایی، ابعاد SOLAP کلاسیک متصل به ویژگی‌های فضایی باقی می‌مانند در حالی که ابعاد فضایی محور X و Y یک سیستم مرجع مختصات هستند. این مدل را می توان با استفاده از داده های شطرنجی به منظور مدیریت فیلدهای پیوسته در یک SOLAP پیاده سازی کرد.

2.4. پیاده سازی OLAP

مکعب های داده OLAP را می توان به دنبال استراتژی های مختلف پیاده سازی کرد. محبوب ترین آنها OLAP چند بعدی (MOLAP) و OLAP رابطه ای (ROLAP) [ 26 ] هستند.

از یک طرف، MOLAP بدیهی ترین استراتژی به نظر می رسد زیرا مکعب های داده را به عنوان آرایه های چند بعدی ذخیره و مدیریت می کند. بنابراین عملیات MOLAP نسبتاً آسان است زیرا اجرای آنها به تعریف مفهومی آنها بسیار نزدیک است. با این وجود، کارایی MOLAP به چگالی مکعب های داده بستگی دارد. در واقع، هنگامی که آنها با ابعاد متعدد و دقیق مشخص می شوند، مکعب های داده MOLAP احتمالا مقدار زیادی از مقادیر بی فایده تهی را ذخیره می کنند (مسئله با چگالی کم). در واقع، برخی از سلول‌های مکعب داده، یعنی تقاطع‌های ابعادی یا واقعیت‌ها، در داده‌ها وجود ندارند. در حوزه GIS، این مشکل کاملاً شبیه به داده‌های شطرنجی است که شامل مقادیر بی‌شمار «بدون داده» است [ 19 ].

از سوی دیگر، ROLAP از انبارهای داده رابطه ای برای ذخیره مکعب های داده استفاده می کند [ 11 ]. سلول های مکعب داده ردیف هایی از یک جدول واقعیت هستند که برای مقادیر تهی نیازی به ذخیره سازی ندارند. بنابراین، ROLAP به طور موثر مکعب های داده را شامل ابعاد متعدد و دقیق مدیریت می کند، اما آنها به پرس و جوهای پیچیده SQL (زبان پرس و جو ساختاریافته) برای نمایش چند بعدی در رابط های OLAP نیاز دارند. این جنبه را می توان توسط ابزارهای اختصاصی OLAP مانند Mondrian [ 27 ] یا PowerBI [ 28 ] مدیریت کرد که امکان جستجو در انبارهای داده رابطه ای را از طریق زبان MDX (MultiDimensional eXpression) فراهم می کند.

به دلیل بلوغ GIS در پایگاه های داده رابطه ای [ 29 ]، SOLAP اغلب به عنوان ROLAP پیاده سازی می شود. با این وجود، مطالعات اخیر همچنین اجرای (S)OLAP را در پایگاه‌های داده NoSQL مانند انبارهای اسناد [ 30 ]، پایگاه‌های داده ستون‌گرا [ 31 ] یا نمودارهای RDF (چارچوب توصیف منابع) [ 32 ، 33 ] پیشنهاد می‌کنند.

2.5. مدل سازی OLAP

با توجه به استراتژی های پیاده سازی متعدد، توصیف مدل سازی (S)OLAP در سطح مفهومی مهم است. با توجه به این اصل، طرح واره معروف ستاره [ 11 ] یک مجموعه داده چند بعدی را با استفاده از مفاهیم OLAP مانند بعد، واقعیت، اندازه گیری و غیره توصیف می کند . طرحواره های ستاره ای که عناصر مشترکی مانند اندازه ها یا ابعاد را به اشتراک می گذارند. این امکان مقایسه بین مکعب های ناهمگن داده را از طریق مته در سراسر عملیات فراهم می کند [ 34 ].

مطالعات متعدد SOLAP از یک نماد گرافیکی برای نشان دادن مدل های طرحواره ستاره استفاده می کنند. برخی از فرمالیسم چند بعدی اختصاصی استفاده می کنند [ 21 ، 35 ]. برخی دیگر از نمودار کلاسی زبان مدلسازی یکپارچه استاندارد (UML) برای توصیف طرحواره های ستاره ای (یا فرمالیسم بسیار نزدیک) استفاده می کنند [ 12 ، 22 ، 36 ]. در میان این موارد، برخی پسوندهای UML (نمایه های UML) را پیشنهاد می کنند تا بتوانند ویژگی های مورد نیاز OLAP را توصیف کنند [ 37 ، 38 ]. دیگران یک طرح کلی ستاره ای را با استفاده از متامدل مکعب داده UML توصیف می کنند [ 39 ، 40 ، 41]. در متامدل‌های مکعب داده، مفاهیم OLAP مانند ابعاد، سطوح ابعاد، سلسله مراتب یا معیارها از طریق متاکلاس‌ها مدل‌سازی می‌شوند که در شکل 2 مثال نشان داده شده است. این متاکلاس ها امکان نمونه سازی خودکار طرحواره های ستاره ای را بر اساس پارامترهای تعریف شده توسط کاربران فراهم می کنند. طرح‌واره‌های ستاره‌ای نمونه‌شده احتمالاً می‌توانند با ابعاد و/یا معیارهای مشترک به منظور مدل‌سازی صورت‌های فلکی پیچیده از مکعب‌های داده ناهمگن به هم متصل شوند. به لطف پارامترهای متامدل ذخیره شده در DW، ساختارهای صورت فلکی را می توان توسط یک ابزار اختصاصی (S)OLAP برای اهداف کاوش و مقایسه تفسیر کرد.

3. کارهای مرتبط

سه موضوع شناسایی شده در تحلیل جغرافیایی شامل ابعاد ناهمگن، یعنی تحلیل زمانی (1)، تحلیل چند منطقه ای (2) و تحلیل چند مقیاسی (3)، می تواند با مدیریت مکعب های داده مربوط به ابعاد ناهمگن که احتمالا تغییر در زمان، فضای جغرافیایی و مقیاس جغرافیایی. نویسندگان [ 42 ] به این نکته اشاره می کنند که مسائل 1 (“مدیریت تغییر و زمان”) و 3 (“بررسی سطوح مختلف دانه بندی”) به ندرت در مدل های OLAP موجود وجود دارد (مساله 2 توسط نویسندگان شناسایی نشده است). با توجه به مفاهیمی که قبلا توضیح داده شد، بخش 3.1 ادبیات OLAP مربوط به این سه موضوع را بررسی می کند. از آنجایی که این مقاله راه حلی را بر اساس متامدل مکعب داده پیشنهاد می کند، بخش 3.2بر این جنبه خاص تمرکز می کند. در نهایت، بخش 3.3 ترکیب مختصری از این بررسی های ادبیات را به منظور تعریف سهم ما در حوزه SOLAP ارائه می دهد.

3.1. صورت فلکی OLAP و ابعاد ناهمگن

ادغام ابعاد در حال تحول (یعنی ابعاد در حال تغییر در زمان) در انبارهای داده یک موضوع تحقیقاتی مهم در 20 سال گذشته بوده است که منجر به مفهوم انبارهای داده زمانی (TDW) شده است [ 43 ]. ایده اصلی TDW ذخیره سازی یک ویژگی زمانی معتبر (نقطه زمانی، فاصله زمانی یا عنصر زمانی) است که به هر عنصر از یک مدل چند بعدی نمونه (یعنی عضو، واقعیت و غیره) یا متامدل (یعنی سطح، سلسله مراتب، بعد، مکعب داده و غیره). بنابراین، پشتیبانی SDT از نمونه های در حال تکامل و همچنین طرحواره ها و OLAP می تواند نتایج ثابتی را بر اساس دوره ها و نسخه های متعدد ابعاد ارائه دهد [ 44 ]]. با این حال، از آنجایی که پرس و جوها بر اساس یک توپولوژی زمانی هستند، این راه حل ها با تغییرات ابعادی بسته به ابعاد دیگری غیر از زمان (فضا یا ابعاد موضوعی دیگر) سازگار نیستند.

در [ 22]، یک راه حل جایگزین برای ادغام ابعاد در حال تکامل در یک DW پیشنهاد شده است: یک طرح صورت فلکی که در آن هر مکعب داده، مربوط به یک عضو زمانی، به “ابعاد عمومی” (یعنی به اشتراک گذاشته شده توسط سایر مکعب های داده) و “ابعاد خاص” مرتبط است. (یعنی مخصوص مکعب داده درگیر و بنابراین بسته به زمان). علاوه بر ابعاد در حال تکامل (مسئله تجزیه و تحلیل زمان)، ما معتقدیم که یک صورت فلکی می تواند تغییرات ابعادی را نیز بسته به فضای جغرافیایی در نظر بگیرد (مسئله تجزیه و تحلیل چند قلمرو). در واقع، وابستگی مکعب‌های داده به اعضای بعدی که به زمان اشاره می‌کنند، می‌تواند در واقع به هر عضو بعدی دیگر، از جمله اعضای جغرافیایی، منتقل شود. در مقایسه با یک طرحواره تک ستاره، ابعاد در حال تکامل در صورت های فلکی چگالی مکعب داده پایینی را ارائه می دهند که به راحتی توسط هر دو سیستم MOLAP و ROLAP مطابق با [.22 ]. با این وجود، این راه حل نیاز به یک مدیریت موثر ناوبری صورت فلکی به منظور انتخاب مکعب(های) داده مناسب برای پاسخگویی به درخواست کاربر دارد. متأسفانه، این جنبه توسط [ 22 ] پوشش داده نمی شود، اما احتمالاً می تواند توسط یک متامدل اقتباس شده کنترل شود.

در [ 45 ]، یک فرمالیسم گرافیکی برای حمایت از مدل سازی مفهومی یک DW پیشنهاد شده است. ساختارهای چند بعدی به‌عنوان نمودارهای شبه درختی به نام «طرح‌های واقعیت» مدل‌سازی می‌شوند که می‌توانند برای پشتیبانی از پرس‌و‌جوهای مته‌ای همپوشانی داشته باشند. نویسندگان در مورد امکان گنجاندن زمان به عنوان بعد از مدل خود برای رسیدگی به طرحواره های در حال تحول بحث می کنند. باز هم، این ایده را می توان به فضا در رابطه با تعاریف ابعاد بسته به قلمروها تعمیم داد.

در [ 46 ]، یک جبر کاربر گرا برای تعریف عملیات OLAP بر اساس یک صورت فلکی چند بعدی پیشنهاد شده است. با این حال، بیشتر عملیات توصیف شده محدود به پیمایش در داخل یک مکعب داده است ( قرار دادن ، دریل کردن ، چرخش ، و غیره). تنها بهره برداری از صورت فلکی در انتخاب یک مکعب داده خاص (“DISPLAY”) و عملیات معمولی مته در سراسر (“FROTATE”) برای مقایسه ابعاد اشتراک گذاری حقایق نهفته است. ناوبری در صورت فلکی از طریق عملیات در ابعاد ناهمگن (به عنوان مثال، بعد متغیر با زمان) در نظر گرفته نمی شود.

علاوه بر ابعاد مشترک، برخی مطالعات جالب نشان می‌دهند که صورت‌های فلکی را می‌توان با روابط بین ستاره‌ای انعطاف‌پذیرتر مشخص کرد. در [ 47 ، 48 ]، دریل کنیدعملیات از شباهت های معنایی بین ابعاد مختلف (بعد-بعد)، حقایق مختلف (واقعیت-واقعیت) یا ابعاد و واقعیت ها (بعد-واقعیت) استفاده می کند. این روابط در سه دسته تعمیم، تداعی و اشتقاق دسته بندی می شوند. به دنبال این رویکرد، ما معتقدیم که روابط واقعیت-واقعیت را می‌توان به عنوان مجموعه‌هایی که توسط سلسله مراتب بعد تعریف می‌شوند طبقه‌بندی کرد. ما پیشنهاد می‌کنیم که این را به‌عنوان صورت‌های فلکی مدل‌سازی کنیم که در آن مکعب‌های داده سطوح ابعاد را به اشتراک می‌گذارند (به‌جای ابعاد مشترک سنتی). در نتیجه، صورت‌های فلکی را می‌توان از طریق عملیات جمع‌کردن فضایی بین ستاره‌ای و عملیات حفاری فضایی زمانی که سطوح مشترک جغرافیایی هستند هدایت کرد (مساله تحلیل چند مقیاسی).

3.2. متامدل های مکعب داده

اساساً، متامدل‌های OLAP ابرداده‌های مربوط به انبارهای داده را برای اهداف تعاملی ذخیره می‌کنند. بر اساس این اصل، گروه مدیریت اشیا (OMG) استانداردی به نام متامدل انبار مشترک (CWM) [ 49 ] پیشنهاد می کند. هدف CWM یکپارچه سازی انبار داده و ابزارهای BI بر اساس ابرداده مشترک است. از XMI (XML Metadata Exchange) برای تبادل ابرداده و UML برای نمایش متامدل های مختلف از جمله OLAP استفاده می کند. متامدل OLAP پیشنهاد شده توسط CWM ( شکل 3) مفاهیم چند بعدی (مکعب داده، بعد، سلسله مراتب، سطح، و غیره) را به عنوان کلاس هایی که توسط انجمن ها به هم متصل شده اند تعریف می کند. بنابراین، می‌توان از آن برای کمک به یکپارچه‌سازی مکعب داده و همچنین ناوبری در یک صورت فلکی استفاده کرد. متأسفانه، با مسئله تحلیل چند مقیاسی ما سازگار نیست. در واقع، متامدل مکعب های داده را با ابعاد مشترک در نظر می گیرد در حالی که ابعاد داده ها نیز می تواند به سطوح سلسله مراتب خاصی از ابعاد بستگی داشته باشد (مساله تجزیه و تحلیل چند مقیاسی). به عبارت دیگر، پیمایش در یک صورت فلکی CWM از طریق roll up و drill down مجاز نیست زیرا سطوح ویژگی های انحصاری ابعاد هستند [ 50 ].

سایر متامدل‌های UML در ادبیات OLAP برای اهداف مختلف پیشنهاد شده‌اند. در [ 41 ]، کیفیت داده DW فضایی با استفاده از محدودیت های یکپارچگی کنترل می شود. در [ 44 ]، متامدل COMET تغییرات روی عناصر چند بعدی را در یک TDW پیگیری می کند. مطالعات دیگر متامدل‌هایی را برای کمک به توسعه‌دهندگان برای طراحی مکعب‌های داده [ 51 ] یا گنجاندن OLAP در معماری‌های کلان داده [ 40 ] پیشنهاد می‌کنند. در نهایت، مطالعات جدیدتر از متامدل‌ها برای اجرای خودکار مکعب‌های داده بر اساس مدل‌های مفهومی [ 52 ] (معماری مبتنی بر مدل) و برای نمونه‌سازی خودکار مکعب‌های داده بر اساس منابع داده خارجی [ 39 ] استفاده می‌کنند.]. مانند CWM، اکثر این متامدل‌های UML به مکعب‌های داده اجازه می‌دهند تا ابعاد را به اشتراک بگذارند اما ناوبری صورت فلکی را در عمق بیشتر در نظر نمی‌گیرند.

3.3. سنتز

این بررسی ادبیات نشان می دهد که تغییرات زمانی ابعاد OLAP در طول 20 سال گذشته به خوبی پوشش داده شده است. با این حال، تغییرات ابعاد بسته به فضا و مقیاس جغرافیایی بسیار کمتر مورد مطالعه قرار گرفته است، اما احتمالاً می تواند توسط یک صورت فلکی اقتباس شده مدیریت شود. از سوی دیگر، آثار متعددی از متامدل‌های UML برای OLAP بهره‌برداری می‌کنند، اما، تا آنجا که ما می‌دانیم، هیچ‌کدام از آنها عمیقاً بر توانایی خود در هدایت ناوبری در صورت فلکی مکعب داده تمرکز نمی‌کنند، به‌ویژه با در نظر گرفتن هر سه جنبه تحلیل جغرافیایی که شامل ابعاد ناهمگن است. : تجزیه و تحلیل چند منطقه ای، تجزیه و تحلیل چند مقیاسی و تحلیل زمانی. این سهم اصلی این مقاله در زمینه SOLAP است.

4. مطالعه موردی و فرضیه تحقیق اقتصاد اجتماعی

4.1. مطالعه موردی اقتصاد اجتماعی

این تحقیق بخشی از یک پروژه بزرگتر به نام VISES است. در یک رویکرد فراملیتی از جمله منطقه فرانسوی هاوت دو فرانس و همچنین مناطق بلژیکی والونیا و فلاندر، هدف آن برجسته کردن این است که چگونه شرکت‌های اقتصاد اجتماعی به پویایی سرزمین‌ها و رفاه ساکنان آن‌ها کمک می‌کنند [ 53 ]. . این روش شامل طراحی، آزمایش و انتشار یک سیستم مناسب برای کارآفرینی اجتماعی به منظور بهبود تأثیر اجتماعی است. پروژه VISES شامل بازیگران مختلفی از جمله شبکه های اقتصاد اجتماعی، موسسات مالی اجتماعی و محققان دانشگاهی است.

این پروژه شامل توسعه یک پلتفرم وب به نام “راسینز” است که به هر بازدید کننده ای اجازه می دهد تا از SOLAP برای کشف داده های اقتصاد اجتماعی استفاده کند. همانطور که در شکل 4 نشان داده شده است ، داده های قابل کاوش توسط مدیران در تمام طول عمر پلت فرم وارد می شوند. این مدیران متخصصان اقتصاد اجتماعی فرانسوی [ 54 ] و بلژیکی [ 55 ] هستند که می خواهند پس از تولید مستقل از متخصصان فناوری اطلاعات باقی بمانند. بیایید توجه داشته باشیم که “راسینز” به اشتراک گذاری داده ها توسط شرکت ها نیز اجازه می دهد، اما این جنبه در این مقاله مورد بحث قرار نخواهد گرفت.

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

اندازه شرکت (به عنوان مثال، کمتر از 5 کارگر، از 5 تا 10 کارگر)،
حوزه فعالیت (به عنوان مثال، کشاورزی، سلامت انسان)،
خانواده اقتصاد اجتماعی (به عنوان مثال، انجمن، تعاون، بنیاد، جامعه متقابل)،
زمان (سال)،
نهاد اداری (به عنوان مثال، استان لیژ، بخش پاریس).

در مجموعه داده‌های مربوط به ایستگاه‌های کاری، اندازه‌گیری «تعداد ایستگاه‌های کاری» نیز می‌تواند به این ابعاد اضافی بستگی داشته باشد:

ارتباط جنسی،
سن،
طبقه بندی اجتماعی-حرفه ای (به عنوان مثال، کارمند، کارگر).

علاوه بر جنبه چند بعدی داده های اقتصاد اجتماعی، ابزار SOLAP “راسینز” باید با سه موضوع زیر مرتبط با ناهمگونی داده ها روبرو شود.

اولین مسئله، تجزیه و تحلیل چند قلمرو است. در واقع، کاربر باید بتواند نقشه‌هایی را که هر دو نهاد اداری بلژیک و فرانسه را در سطوح مختلف نشان می‌دهند، کاوش کند: سطح 1 شامل کمون‌های بلژیک و EPCI فرانسه (“Établissement public de coopération intercommunale”)، سطح 2 شامل استان‌های بلژیک و بخش‌های فرانسه، سطح 3 شامل مناطق بلژیک و مناطق فرانسه است (این سطوح مقایسه توسط متخصصان اقتصاد اجتماعی بر اساس میانگین اندازه و جمعیت نهادهای اداری تعریف شده است.). با این حال، این داده‌ها در سطح ملی جمع‌آوری می‌شوند و در نتیجه معنای متفاوتی دارند. در واقع، بعد “منطقه فعالیت” در فرانسه با بلژیک یکسان نیست. به عنوان مثال، در سطح 1 (EPCI و کمون ها)، داده های بلژیکی 20 دسته دارند در حالی که داده های فرانسوی فقط 8 دسته دارند. این دسته بندی ها با واژگان مختلف تعریف می شوند. این امر بر اهمیت سپردن یکپارچه سازی داده ها به متخصصانی که قادر به برقراری روابط صحیح بین این طبقه بندی های مختلف هستند تأکید می کند.

موضوع دوم تحلیل چند مقیاسی است که شامل تغییرات معنایی در داده ها نیز می شود. در واقع، به دلیل محرمانه بودن آماری، داده های فرانسوی با همان سطح جزئیات در هر سطح مقیاس در دسترس نیستند. به عنوان مثال، بعد “اندازه شرکت” در سطح منطقه و بخش وجود دارد اما در سطح EPCI وجود ندارد. لازم به ذکر است که هم یکپارچه سازی داده ها و هم کاوش داده ها تحت تأثیر این عدم دسترسی قرار می گیرند.

موضوع سوم تحلیل زمان است. همه ابعاد احتمالاً در طول زمان تغییر خواهند کرد، به ویژه نهادهای اداری. به عنوان مثال، تعداد کمون‌های بلژیک از 589 به 581 به دلیل ادغام‌های اداری در سال 2019 کاهش یافته است. ترکیب‌های دیگری احتمالاً برای سال 2024 برنامه‌ریزی شده است. مثال دیگر تکامل بعد “منطقه فعالیت” است که شامل دسته‌های جدید، دسته‌های حذف شده یا تعریف مجدد معنایی است. دسته های قبلی در هر دو کشور بنابراین مدل متام ما باید تغییرات گذشته و همچنین تغییرات آینده در ابعاد داده را در نظر بگیرد.

4.2. فرضیه تحقیق

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

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

با توجه به ادبیات بررسی شده قبلی، فرضیه تحقیق ما ایجاد یک متامدل UML SOLAP است که قادر به تولید طرحواره های ستاره ای به هم پیوسته (صورت فلکی) به منظور حرکت بین مکعب های داده های فضایی ناهمگن با سطوح ابعاد مشترک است. متامدل باید بتواند مکعب‌های داده‌ای مناسب را پیدا کند که به تحلیل فضایی یا جمع‌آوری آن برای تجزیه و تحلیل چند مقیاسی پاسخ می‌دهند و برای تجزیه و تحلیل زمانی و چند منطقه‌ای مته می‌شوند. پس از آن، این متامدل در یک زیرساخت BI شامل یک انبار داده رابطه ای (ROLAP)، یک ماژول یکپارچه سازی داده، یک ماژول اکتشاف (SOLAP) و یک ماژول گزارش پیاده سازی خواهد شد.

5. متامدل

این بخش به متامدل اصلی ترجمه شده از فرضیه تحقیق ما، یعنی متامدلی برای مدیریت مکعب های داده ناهمگن در صورت فلکی که با سطوح ابعاد مشترک مشخص می شود، اختصاص دارد. بر اساس مفاهیم SOLAP ارائه شده در بخش 5.1 ، متامدل مکعب داده با زبان UML در بخش 5.2 رسمیت یافته است . به منظور در نظر گرفتن موضوع مربوط به تجزیه و تحلیل چند مقیاسی، از ارتباط مکعب های داده با سطوح ابعاد استفاده می شود. نمونه‌هایی از مکعب‌های داده نمونه‌سازی شده توسط متامدل، به دنبال دو استراتژی پیاده‌سازی متفاوت، در بخش 5.3 آورده شده‌اند . در نهایت، بخش 5.4مفهوم اصلی “فرابعد” را با در نظر گرفتن مسائل مربوط به تجزیه و تحلیل چند قلمرو و تحلیل زمانی توصیف می کند.

5.1. مفاهیم SOLAP

یک مکعب داده با یک ساختار چند بعدی مشخص می شود که می تواند توسط یک طرحواره ستاره [ 11 ] تعریف شود. یک مثال در شکل 5 آورده شده است. این مدل مفهومی هر بعد (شاخه های قرمز ستاره) یک مجموعه داده اقتصادی در مورد شرکت ها را نشان می دهد. هر بعد با مجموعه‌ای از اعضا مشخص می‌شود که با سطوح مرتب شده (با نماد سبز) سلسله مراتبی دارند. به عنوان مثال، بعد “منطقه فعالیت” شامل سه سطح است: “همه”، “نوع شناسی A” و “نوع شناسی B”. “نوع شناسی B” جزئی ترین سطح است (یا به سادگی “سطح تفصیلی” نامیده می شود) که می تواند شامل اعضای زیر باشد: “آموزش ابتدایی” ، “آموزش متوسطه” ، “آموزش عالی” و غیره. “نوع شناسی A” یک سطح با جزئیات کمتر است. سطحی که می تواند شامل “آموزش” در میان سایرین باشد. در این سلسله مراتب، اعضای سطح “گونه شناسی B” می توانند فرزندان سطح “نوع شناسی A” باشند (“آموزش ابتدایی، “آموزش متوسطه”، “آموزش عالی” همه متعلق به “آموزش و پرورش” هستند). سرانجام، سطح “همه” فقط شامل یک عضو است که والد هر عضو “Typology A” است. به لطف سلسله مراتب ابعاد، OLAPعملیات drill down و roll up را می توان برای تغییر دانه بندی داده ها انجام داد. توجه داشته باشید که فقط سلسله مراتب ساده در شکل 5 مثال در نظر گرفته شده است. سلسله مراتب پیچیده تر، مانند سلسله مراتب چندگانه یا سلسله مراتب موازی، را می توان از طریق فرمالیسم های دیگر توصیف کرد [ 35 ].

شکل 5 همچنین یک بعد جغرافیایی (نماد به صورت مورب) را نشان می دهد، “موجودات اداری” که توسط اعضای جغرافیایی مشخص می شود. یک عضو جغرافیایی یک تعریف معنایی دارد (مثلاً نام “استان لیژ”) و یک تعریف فضایی (مثلاً هندسه “استان لیژ” [ 16 ]). بر خلاف سایر ابعاد، ابعاد جغرافیایی را می توان بر روی نقشه نشان داد (به عنوان مثال، نمایش سطح “ولایات” به عنوان چند ضلعی دو بعدی). ابعاد دیگر را می توان در جداول یا نمودارها و همچنین ابعاد جغرافیایی به لطف تعریف معنایی آنها نشان داد. هنگامی که OLAP با ابعاد جغرافیایی مشخص می شود، تبدیل به SOLAP [ 17 ] می شود. لازم به ذکر است که ابعاد زمانی نیز می تواند مدیریت خاصی در مورد چرخه های زمانی مانند ساعت ها، هفته ها، فصول و غیره داشته باشد [ 56 ]].

در مرکز طرح ستاره، معیارها به رنگ آبی نشان داده می شوند (به عنوان مثال، “تعداد شرکت ها”، “تعداد کارگران”، و غیره). آنها بسته به اعضای بعدی که به آنها متصل شده اند، داده های انباشته می شوند. در مثال ما، معیارهای متصل به یک عضو بعد والد، مجموع جمع اعضای فرزند آن است. به همین دلیل، بعد زمانی تنها موردی است که با یک سطح واحد (“سال”) مشخص می شود زیرا اضافه کردن تعداد سالانه شرکت ها در سطح “همه” معنی ندارد.

در نهایت، طرح ستاره حقایقی را نشان می دهد که عناصر قابل تجزیه و تحلیل نشان داده شده در رابط های مختلف SOLAP (جدول، نمودار، نقشه) هستند. یک واقعیت از یک عضو در هر بعد طرح واره ستاره تشکیل شده است و یک مقدار اندازه گیری می تواند به هر واقعیت مرتبط باشد. برای مثال، یک واقعیت می‌تواند تعداد شرکت‌ها (میزان اندازه‌گیری) در کمون لیژ (بعد «نهاد اداری») با کمتر از 5 کارگر (بعد «اندازه شرکت»)، در بخش ساخت‌وساز (بعد «منطقه فعالیت»)، در سال 2019 باشد. (بعد “زمان”)، همه خانواده ها شامل (بعد “خانواده اقتصاد اجتماعی”). توجه داشته باشید که یک واقعیت شامل یک بعد جغرافیایی به عنوان واقعیت جغرافیایی در نظر گرفته می شود زیرا می تواند بر روی نقشه نمایش داده شود.

یک نمونه طرحواره ستاره یک مکعب داده (یا “دیتا ابرمکعب”) است. شکل 6 نمایش یک مکعب داده را نشان می دهد که از طرح ستاره شکل 5 نمونه برداری شده است. از آنجایی که نمایش گرافیکی یک ابر مکعب پنج بعدی ممکن نیست، تنها سه بعد در نظر گرفته می شود. با این وجود، یک مکعب داده با ابعاد n را می توان به طور موثر در یک انبار داده مدیریت کرد.

مکعب داده مجموعه ای از هر واقعیت ممکن با در نظر گرفتن یک سطح در هر بعد از طرح ستاره است. به عبارت دیگر، یک مکعب داده با n بعد حاصلضرب دکارتی از n مجموعه از اعضا به نام «سطوح ابعاد» است. هر سلول از مکعب داده یک واقعیت است که با ابعاد مختصات نمایه می شود و ابعاد مختصات در واقع شناسه اعضای بعد هستند.

تمام نمونه های یک طرحواره ستاره ای شبکه ای از مکعب ها را تشکیل می دهند که مجموعه ای از هر مکعب داده ممکن بر اساس یک طرحواره ستاره واحد است [ 18 ، 57 ]. به عبارت دیگر، با در نظر گرفتن یک سطح در هر بعد (محصولات دکارتی سطوح ابعاد) برای هر ترکیب ممکن از سطح ابعاد، یک مکعب وجود دارد. جزئی ترین مکعب، که مکعب پایه نامیده می شود، با جزیی ترین سطح ابعاد (حقایق دقیق) تعریف می شود. در مثال ما، مکعب اصلی با “کمون”، “سال”، “نوع شناسی B”، “اندازه شرکت” و “خانواده” تعریف می شود. تمام اندازه های دیگر مکعب ها تجمعی از مکعب اصلی هستند. سپس عملیات دریل کردن و جمع کردن OLAP را می توان با پیمایش در شبکه مکعبی انجام داد.شکل 7 شبکه ای از مکعب ها را بر اساس این دو بعد نظری نشان می دهد: {A, B, all} و {1, 2, all}. عملیات متداول SOLAP مانند سوراخ کردن و رول کردن با نمونه های ملموس بلژیکی در پاراگراف های زیر نشان داده شده است.

شکل 8 ، ابعاد « مجموعه اداری » را نشان می دهد . به عنوان یک بعد جغرافیایی، تعریف فضایی آن (چند ضلعی های هندسی) در رابط نقشه نشان داده می شود. معیارهای «تعداد شرکت‌ها» مرتبط با حقایق جغرافیایی با تنوع رنگی هندسه‌های چند ضلعی (اعضای سطح) نشان داده می‌شوند. حفاری در سطح “منطقه” و به ویژه در عضو “Vlaams Gewest” انجام می شود. نتیجه، مجموعه ای از حقایق جغرافیایی مرتبط با اعضای سطح پایین «ولایت» است که متعلق به عضو حفاری شده «ولامس گیوست» است. رول کردن به سادگی عمل معکوس است. در ادبیات SOLAP، دریل کردن و رول کردناعمال شده در یک بعد جغرافیایی به ترتیب فضایی دریل پایین و فضایی رول کردن نامیده می شوند . به لطف توانایی آنها برای تغییر سریع از مقیاس جهانی به مقیاس محلی تر (و بالعکس)، این عملیات برای اکتشاف فضایی داده های بزرگ جغرافیایی بسیار کارآمد هستند. علاوه بر رابط نقشه، حفاری فضایی را می توان بر روی واسط های دیگر (نمودار یا جداول) نشان دهنده ابعاد جغرافیایی و/یا سایر ابعاد غیرجغرافیایی انجام داد. در واقع، این توانایی تغییر از یک رابط به رابط دیگر یک مزیت ارزشمند SOLAP در کاوش داده های بزرگ است.

لازم به ذکر است که برای مقایسه‌های مربوط به موجودیت‌های گسسته فضایی، معیارها باید مستقل از سطحی باشند که به آن متصل می‌شوند. بنابراین آنها باید به تراکم هایی مانند شرکت در واحد سطح یا شرکت در واحد جمعیت تبدیل شوند. این جنبه را می توان با مفهوم «اندازه گیری مشتق شده» که در بخش 5.2 توضیح داده شده است، مدیریت کرد .

در نهایت، شکل 9 یک عملیات برش را در هر دو رابط نقشه ها ( شکل 9 الف) و نمودارها ( شکل 9 ب) نشان می دهد. از یک سو، نقشه‌ها سطح جغرافیایی «استان» حاصل از عملیات حفاری را نشان می‌دهند که در شکل 8 نشان داده شده است. از سوی دیگر، نمودارها سطح ابعاد «اندازه شرکت» را در ردیف‌ها و سطح جغرافیایی «منطقه» را در رنگ‌ها نشان می‌دهند (در واقع، تنها یک منطقه در این مثال به رنگ آبی نشان داده شده است). اقدامات ارائه شده هنوز “تعداد شرکت ها” هستند. عملیات برش ، زیرمجموعه ای از مکعب های داده را بر اساس یک عضو خاص با یک یا چند بعد جدا می کند. بر اساس این اصل، نمودارهای شکل 9b در ابتدا با “Vlaanderen” (یعنی عضو سطح جغرافیایی “منطقه” به رنگ آبی نشان داده شده است) برش داده می شوند. با این حال، برش نشان‌داده‌شده شکل همان است که در بعد «خانواده» (یعنی خانواده اقتصاد اجتماعی) برای هر دو رابط اعمال می‌شود. بنابراین، در بالای شکل، حقایق ارائه شده به همه خانواده ها مرتبط است (یعنی سطح “همه” بعد “خانواده”). در شکل پایین، برشی از “جوامع متقابل” عضو از بعد “خانواده” در نتیجه تغییر تعریف حقایق را نشان می دهد. بنابراین، برش ها در ابعاد مختلف را می توان با هم ترکیب کرد زیرا رابط نمودار دوم هر دو توسط “جوامع متقابل” و اعضای “Vlaanderen” برش داده شده است. تکهمی تواند بر روی ابعاد نمایش داده شده (به عنوان مثال، بعد جغرافیایی در نمودارها) یا ابعاد غیر نمایش داده شده (به عنوان مثال، بعد “خانواده” در نمودارها و نقشه ها) انجام شود. با توجه به ابعاد غیر برش‌خورده، یک سطح نشان‌داده‌شده از ابعاد، همه اعضای متعلق به این سطح را نشان می‌دهد (مثلاً منطقه فعالیت در نمودارها)، در حالی که یک بعد غیرنمایش‌شده در سطح «همه» آن جمع‌آوری می‌شود (مثلاً منطقه فعالیت در نقشه). در نتیجه، یک بعد زمانی غیر نمایش داده شده باید همیشه برش داده شود زیرا طبق طرح شکل 5 شامل هیچ سطح “همه” نمی شود . بنابراین، در شکل 9 نمونه نیز تا سال 2015 برش داده شده است.

5.2. متامدل مکعب داده

این بخش به فرامدل اصلی این تحقیق اختصاص دارد. به عنوان یک نمودار کلاس UML در شکل 10 رسمیت یافته است . بر اساس مفاهیم مکعب داده تعریف شده در بخش قبل، این متامدل قادر است به طور خودکار نمونه های مکعب داده را در یک صورت فلکی تولید و مدیریت کند. به منظور مدیریت ابعاد ناهمگن در تحلیل چند مقیاسی، تحلیل چند قلمرو و تحلیل زمانی، دو رویکرد اصلی در متامدل پیشنهاد شده است.

در اکثر متامدل های UML ارائه شده در ادبیات، مکعب های داده به ابعاد مرتبط هستند. متامدل ما از رویکرد متفاوتی پیروی می کند: مکعب های داده مستقیماً با سطوح ابعاد مرتبط هستند. این امکان پیمایش بین مکعب های مختلف داده را از طریق عملیات جمع کردن و دریل کردن فراهم می کند. در واقع، تجزیه و تحلیل چند مقیاسی باید تغییرات در ابعاد غیر جغرافیایی را بسته به سطوح ابعاد جغرافیایی در نظر بگیرد.
بر خلاف تجزیه و تحلیل چند مقیاسی که شامل تغییرات بسته به سطح بعد است، دو هدف دیگر ما، یعنی تجزیه و تحلیل چند قلمرو و زمان، باید تغییرات بسته به اعضای بعد را در نظر بگیرند، یعنی اعضای زمانی برای تجزیه و تحلیل زمانی و اعضای جغرافیایی برای تجزیه و تحلیل چند قلمرو. این جنبه از طریق یک مفهوم فرابعدی توضیح داده شده در بخش 5.4 مدیریت می شود .

اگرچه برای یک کاربرد خاص، به عنوان مثال، اکتشاف و گزارش داده‌های اقتصاد اجتماعی توسعه یافته است، این متامدل می‌تواند برای SOLAP در زمینه‌های دیگر شامل داده‌های گسسته فضایی استفاده شود. علاوه بر این، این متامدل مفهومی به هیچ سیستم مدیریت پایگاه داده (DBMS) وابسته نیست. هر متاکلاس نشان داده شده در شکل 10 در پاراگراف های زیر مورد بحث قرار گرفته است.

دیتاکیوب متاکلاس مرکزی است. حداقل با یک سطح بعد ( سطح متاکلاسی ) و حداقل یک معیار (میزان متاکلاسی) مرتبط است .). هنگامی که نمونه سازی می شود، یک مدل مکعب داده جدید تولید می کند. همانطور که قبلاً توضیح داده شد، ارتباط مستقیم مکعب های داده با سطوح ابعاد به ویژه زمانی مفید است که ابعاد داده ها (و/یا اندازه گیری ها) بسته به سطح بعدی دیگر تغییر کند. این مورد در برنامه ما است زیرا معناشناسی داده ها به مقیاس جغرافیایی (به دلیل محرمانه بودن آماری) بستگی دارد. به عنوان مثال، داده های فرانسوی از جمله بعد “اندازه شرکت” در سطح بخش و منطقه در دسترس است اما در سطح EPCI نیست. در نتیجه، سطح جزییات نسبی ابعاد برای یک مکعب داده خاص، لزوماً سطح جزئی مطلق بعد نیست. به عنوان مثال، اگر یک سطح “منطقه” مستقیماً به یک مکعب داده متصل شود، به سطح دقیق برای این مکعب داده خاص تبدیل می شود.

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

در یک بعد، سطوح با ویژگی عدد صحیح level_rank سطح متاکلاس سلسله مراتب می شوند . این یک موقعیت سلسله مراتبی مطلق را نشان می دهد که امکان نمایش ابعادی را که با سلسله مراتب موازی مشخص می شوند را فراهم می کند. با توجه به ابعادی با رتبه های سطح n ، جزئی ترین سطوح با 0 و سطوح با جزئیات کمتر با n – 1 رتبه بندی می شوند. نمایش و مقایسه سلسله مراتب موازی امکان پذیر است زیرا سطوح مختلف یک بعد واحد احتمالاً می توانند رتبه یکسانی داشته باشند. برای مثال، اگر سطوح «دپارتمان‌های فرانسوی» و «استان‌های بلژیکی» هر دو با 1 رتبه‌بندی شوند، یک SOLAP می‌تواند این سطوح قابل مقایسه را در یک نقشه فرامرزی با استفاده از سطح_رتبه‌های دارایی نشان دهد..

سطح Metaclass امکان نمایش حقایق را در رابط های OLAP مانند نمودارها (مثلاً اعضای سطح به عنوان محور X و اندازه گیری به عنوان محور Y ) یا جداول (مثلاً اعضای سطح به عنوان ردیف و اندازه گیری به عنوان ستون) را فراهم می کند. یک سطح به شدت به یک بعد ( بعد متاکلاسی ) تعلق دارد. سلسله مراتب تداعی بازگشتی سطوح برتر مستقیم ( والد ) و سطوح پایین مستقیم ( فرزند ) یک نمونه سطح را تعریف می کند. این به متامدل اجازه می‌دهد سلسله مراتب ابعادی از مکعب‌های داده نمونه‌سازی شده بسازد و drill_down (یعنی فراخوانی سطح فرزند) و همچنین roll_up را انجام دهد.(یعنی فراخوانی سطح والد) در این سلسله مراتب. با این حال، برای ثابت ماندن، باید یک محدودیت در رابطه با level_rank ویژگی تعریف شود : با در نظر گرفتن سطح رتبه‌بندی شده توسط i ، سطوح والد آن باید با i + 1 و سطح فرزند آن باید با i – 1 رتبه‌بندی شوند.

Metaclass Level همچنین با ویژگی بولی “is_all” مشخص می شود که نشان می دهد سطح “همه” است یا خیر. این ویژگی می تواند توسط SOLAP زمانی استفاده شود که یک بعد مکعب داده در تجزیه و تحلیل نادیده گرفته شود، که برابر است با جمع کردن مکعب داده به سطح “همه” این بعد. لازم به ذکر است که سطح متاکلاس با خاصیت بولی is_meta نیز مشخص می شود که در بخش 5.4 مورد بحث قرار خواهد گرفت .

سطوح می توانند توسط چندین مکعب داده به اشتراک گذاشته شوند تا بتوان صور فلکی مکعب داده را مدیریت کرد. این جنبه امکان مقایسه مکعب های داده را بر اساس سطوح ابعاد مشترک آنها فراهم می کند. به عنوان مثال، حتی اگر فرانسه و بلژیک نوع‌شناسی‌های متفاوتی برای بعد «حوزه فعالیت» داشته باشند، متامدل همچنان می‌تواند نموداری را ترسیم کند که تعداد شرکت‌ها را در هر خانواده اقتصاد اجتماعی (سطح مشترک «خانواده») برای هر دو کشور شامل تمام حوزه‌های فعالیت نشان می‌دهد. به عبارت دیگر، بعد “حوزه فعالیت” توسط تحلیل نادیده گرفته می شود). این عملیات OLAP، مته در عرض [ 34 ] نامیده می شود. به اشتراک گذاری سطوح ابعاد همچنین به یک رابط OLAP اجازه می دهد تا از وضعیت سطوح رایج (مثلاً برش ) کپی کند“خانواده = جوامع متقابل”) هنگام تغییر از یک مکعب داده به مکعب دیگر. بنابراین، این جنبه سازگاری ناوبری را بین مکعب‌های داده متفاوت از لحاظ معنایی تقویت می‌کند. توجه داشته باشید که برای باقیمانده این مقاله، چندین مکعب داده حداقل یک سطح از یک بعد را به اشتراک می گذارند، ما از عبارت “بعد مشترک” برای اشاره به این بعد استفاده می کنیم (حتی اگر سطوح دیگر این ابعاد رایج نباشند).

Metaclass Level می تواند در سطح جغرافیایی تخصصی باشد. این فراکلاس کودک شامل ابرداده های مکانی است که امکان نمایش حقایق را بر روی نقشه ها فراهم می کند (به عنوان مثال، اعضای جغرافیایی به عنوان هندسه و اندازه گیری ها به عنوان نماد). بنابراین یک سطح جغرافیایی با یک نوع موجودیت فضایی (به عنوان مثال، نقطه، خط، چند ضلعی، چند نقطه، و غیره)، یک نام ویژگی مکانی برای هندسه های آن و یک سیستم مرجع مختصات که توسط شناسه مرجع فضایی آن (SRID) ارائه می شود، مشخص می شود. توجه داشته باشید که یک بعد در صورتی جغرافیایی محسوب می شود که حداقل یک سطح جغرافیایی را شامل شود.

ویژگی Metaclass به هر سطح، جغرافیایی یا غیر جغرافیایی اجازه می دهد تا ویژگی های اضافی را شامل شود. به عنوان مثال، می تواند یک جمعیت یا یک منطقه وابسته به نهادهای اداری جغرافیایی باشد. این ویژگی‌ها احتمالاً می‌توانند برای محاسبه معیارهای مشتق‌شده مانند تراکم (به عنوان مثال، تعدادی شرکت در هر 1000 نفر یا تعدادی شرکت در هر کیلومتر مربع) استفاده شوند. یک ویژگی می تواند از هر نوع باشد (رشته، واقعی، عدد صحیح و غیره).

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

در نهایت، هر متاکلاس با یک شناسه (id) منحصر به فرد مشخص می شود که برای نمونه سازی مدل های مکعب داده برای ماشین استفاده می شود. هر متاکلاس همچنین شامل یک ویژگی توضیحات است که در رابط های OLAP برای ارائه عناصر به انسان استفاده می شود.

5.3. نمونه مدل مکعب داده نمونه

این بخش روشی را نشان می‌دهد که مدل‌های مکعب داده از متامدلی که قبلاً توضیح داده شد، نمونه‌سازی می‌شوند. این مدل‌های نمونه‌سازی شده با استفاده از فرمالیسم مشابه متامدل توصیف می‌شوند: نمودار کلاس UML. به منظور تفکیک واضح دو سطح مفهوم‌سازی، ما همیشه از اصطلاح «متاکلاس» برای اشاره به متامدل و از واژه «کلاس» برای اشاره به مدل‌های نمونه استفاده می‌کنیم. متامدل و مدل‌ها با اصل زیر به هم متصل می‌شوند: نمونه‌های متاکلاس یا کلاس‌ها یا ویژگی‌های کلاس در مدل‌های نمونه می‌شوند.

توضیحات زیر بر اساس یک مثال عمومی از مکعب داده نمونه است. با این جنبه ها مشخص می شود:

یک مکعب داده به عنوان “datacubeA” (ویژگی datacube_id در metamodel) شناسایی شده است.
دو بعد به ترتیب به عنوان “dimensionA” و “dimensionB” (ویژگی dimension_id در metamodel) شناسایی شدند.
“dimensionA” شامل دو سطح به ترتیب “dimensionA_level0” و “dimensonA_level1” (property level_id در metamodel) است.
“dimensionB” شامل دو سطح جغرافیایی به ترتیب “dimensionB_level0” و “dimensonB_level1” (property level_id در metamodel) است.
“datacubeA” شامل کل بعد “dimensionA” است.
“datacubeA” فقط شامل سطح “dimension_level1” بعد “dimensionB” است.

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

با وجود سادگی، این مثال جنبه های مهمی از متامدل و کاربرد اجتماعی اقتصادی ما را پوشش می دهد:

یک بعد جغرافیایی برای SOLAP.
یک مکعب داده بسته به یک بعد کامل و در نتیجه امکان حفاری و چرخاندن از طریق مکعب ها را فراهم می کند.
یک مکعب داده بسته به سطح ابعادی خاص برای مدیریت داده‌های ناهمگن و در نتیجه امکان حفاری بین ستاره‌ای و جمع شدن از طریق مکعب‌های داده یک صورت فلکی (به دلیل تغییرات معنایی بسته به مقیاس‌های تحلیل)

شکل 11 مدل نمونه سازی شده برای “dimensionA” و “dimensionB” را نشان می دهد. همه کلاس ها سطوحی هستند که از سطح متاکلاس نمونه سازی شده اند . آنها اعضای سطحی را تعریف می کنند که با ویژگی های Member_id (شناسه مختصات مکعب داده یا ماشین)، Member_description (شناسه برای انسان) و Member_position مشخص می شوند . این ویژگی آخر یک عدد صحیح است که برای ترتیب منطقی اعضا در رابط های OLAP استفاده می شود. به عنوان مثال، اعضای یک سطح “ماه” باید در یک محور نمودار به صورت “ژانویه” (1)، “فوریه” (2)، “مارس” (3)، و غیره ظاهر شوند. توجه داشته باشید که این نقش به سادگی می تواند به Member_id اختصاص داده شود.اگر مدل در یک آرایه DBMS پیاده سازی شود که در آن کلاس های سطح به طور طبیعی به مجموعه های مرتب شده از اعضا تبدیل می شوند (MOLAP). به عنوان ویژگی‌های ذاتی تمام سطوح نمونه‌سازی شده ابعاد، عضو_ id ، Member_description و Member_position نیازی به تعریف صریح در متامدل ندارند. برعکس، ویژگی‌های صفت برای هر سطح بعد خاص هستند. در نتیجه، هر خصیصه ای که قبلاً در ویژگی متاکلاس تعریف شده بود ، به ویژگی ویژگی کلاس های سطح تبدیل می شود (احتمالاً برای محاسبه معیارهای مشتق شده استفاده می شود).

از آنجایی که سطوح “dimensionB” جغرافیایی هستند، کلاس های dimensionB_level0 و dimensionB_level1 با یک ویژگی اضافی مشخص می شوند: geom . توسط ویژگی spatial_attribute از metaclass geographic_level نمونه سازی شده است . با پیروی از استاندارد کنسرسیوم فضایی باز (OGC) [ 16 ]، نوع geom هندسه است و بنابراین شامل تمام داده ها و ابرداده های یک موجودیت فضایی متصل به یک عضو جغرافیایی می شود. این به ویژه شامل مختصات فضایی ویژگی فضایی، نوع ویژگی فضایی (نمونه سازی شده توسط ویژگی entity_type of metaclass geographic_level) و SRID (مشخص شده توسط ویژگی srid از metaclass geographic_level ). بنابراین، هر یک از اعضای جغرافیایی را می توان بر روی نقشه نشان داد و احتمالاً در عملیات GIS مانند محاسبه منطقه، تبدیل به سیستم مرجع مختصات دیگر، برش OLAP بر اساس روابط توپولوژیکی با سایر اعضای جغرافیایی، پردازش جغرافیایی و غیره مشارکت داشت. به عبارت دیگر، سطوح جغرافیایی پل هایی بین فناوری های OLAP و GIS هستند که به SOLAP منتهی می شوند.

سطوح تفصیلی به ترتیب با کلاس های dimensionA_level0 و dimensioB_level0 برای “DimensionA” و “DimensionB” نمایش داده می شوند. سطوح غیرجزئیات، که به ترتیب با کلاس‌های dimensionA_level1 و dimensionB_level1 نشان داده می‌شوند، به‌عنوان والدین سطوح دقیق‌تر بر اساس بعد مالکیت (بعد متاکلاسی ) و سلسله مراتب (سلسله مراتب تداعی بازگشتی در متامدل) ظاهر می‌شوند. بنابراین، هر عضو غیر تفصیلی می تواند والدین یک عضو فرزند متعلق به یک سطح پایین تر باشد.

یک مدل مکعب داده نمونه، یک طرح واره دانه برف است مانند آنچه در شکل 12 ارائه شده است (یک دانه برف UML سطوح ابعاد را به عنوان کلاس ها نشان می دهد در حالی که یک ستاره سطوح را به عنوان ویژگی های کلاس های بعد نشان می دهد [ 11 ]). یک کلاس مرکزی datacubeA (نمونه ای از datacube متاکلاس ) حقایق دقیق را تعریف می کند. این ویژگی با یک یا چند ویژگی اندازه گیری شده توسط اندازه گیری متاکلاس مشخص می شود. در این مثال عمومی، نوع اندازه گیری ویژگی تعریف نشده است زیرا می تواند هر نوع (عدد صحیح، واقعی، رشته و غیره) باشد که توسط نوع خاصیت اندازه گیری متاکلاس ارائه شده است.. با این وجود، معیارها معمولاً مقادیر عددی مانند “تعداد شرکت ها” یا “کل حقوق و دستمزد” هستند.

از آنجایی که یک واقعیت تفصیلی توسط یک عضو از هر سطح تفصیلی بعد (مختصات واقعیت) تعریف می‌شود، datacubeA به هر سطح تفصیلی بعد «dimensionA» و «dimensionB» مرتبط می‌شود: به ترتیب کلاس‌های dimensionA_level0 و dimensionA_level_1 . بنابراین، معیارهای حقایق غیرجزئی را می‌توان با جمع‌آوری معیارهای حقایق دقیق محاسبه کرد، زیرا هر عضو فرزند احتمالاً به یکی از اعضای والدین در سطح برتر متصل است.

با این حال، کاربرد اقتصاد اجتماعی ما به رویکرد متفاوتی برای مدیریت مکعب ها نیاز دارد. در واقع، اگر سیستم قادر به محاسبه آنها (مجموع، شمارش و غیره) باشد، می توان از تجمعات در پرواز استفاده کرد. این موارد در مورد ما قابل اجرا نیستند زیرا داده های فرانسوی موجود شامل معیارهای پایین تر از 3 نیستند. به دلیل محرمانه بودن آماری، این حقایق دارای برچسب “بدون داده” هستند. بنابراین ناتوانی در محاسبه انباشته ها با گنجاندن حقایق مکعبی در کلاس datacubeA ، به دنبال رویکردی مشابه با رویکرد پیشنهادی [ 58 ] برای پشتیبانی از سطوح مختلف دانه بندی در داده ها، حل می شود. در شکل 12 ، حقایق مکعبی با ارتباط اختیاری dimension_fact تعریف شده‌اند(در صورت نیاز به ذخیره مکعب). علاوه بر حقایق دقیق (یعنی مکعب اصلی)، بنابراین مثال ساده ما یک مکعب اضافی را ذخیره می کند که با ترکیب سطوح dimensionB_level و dimensionA_level1 تعریف شده است . در مثالی که شامل سطوح بعدی بیشتر است، یک dimension_factارتباط باید برای تمام سطوح غیر جزئی ابعاد تعریف شود. این پیوندها اختیاری هستند زیرا اکثر DW می توانند مکعب های خود را محاسبه کنند و مکعب های از پیش محاسبه شده را به یک مسئله فیزیکی (به جای مفهومی) تبدیل می کنند تا عملکرد پرس و جوی OLAP را بهبود بخشند. با توجه به کاربرد اقتصاد اجتماعی، ما مکعب‌ها را در مدل‌سازی مفهومی قرار می‌دهیم زیرا بخشی از داده‌های ورودی هستند. به عنوان مثال، داده‌های ورودی شامل اقدامات شرکت مربوط به مقوله «سلامت انسان» برای یک نهاد اداری خاص نمی‌شود، اما این معیارهای غیرقابل دسترس هنوز در سطحی با جزئیات کمتر «کلیه حوزه فعالیت» از داده‌های ورودی محاسبه می‌شوند. در واقع، “بدون داده” به معنای “صفر” نیست.

در نهایت، لازم به یادآوری است که سطح 0 بعد B در مدل وجود ندارد زیرا مثال مکعب داده ما فقط شامل سطح 1 بعد B است (برخلاف بعد A که به طور کامل گنجانده شده است). بنابراین، سطح 1 بعد B به سطح جزئیات این مکعب داده خاص تبدیل می شود.

5.4. فرابعد

در بخش 5.2 ، ما متامدل اصلی خود را شرح دادیم که به مکعب های داده اجازه می دهد سطوح ابعاد را به اشتراک بگذارند تا تجزیه و تحلیل چند مقیاسی شامل ابعاد ناهمگن را مدیریت کنند. با این حال، دو موضوع دیگر مربوط به ابعاد ناهمگن باقی می ماند: تحلیل زمانی و تحلیل چند قلمرو. اینها را می توان به ترتیب توسط مکعب های داده بسته به اعضای خاصی از یک بعد “زمان” و یک بعد “منطقه” مدل سازی کرد. در واقع، در مطالعه موردی اقتصاد اجتماعی ما، تغییرات اعضای بعد می‌تواند در یک سال خاص رخ دهد (به عنوان مثال، تعریف مجدد کمون‌های بلژیک در سال 2019) و ابعاد می‌تواند در بلژیک و فرانسه متفاوت باشد (به عنوان مثال، نوع شناسی منطقه فعالیت). بنابراین لازم است که این وابستگی ها در متامدل مکعب داده نشان داده شده در شکل 10 لحاظ شوند.

پیشنهاد ما این است که ابعاد نمونه‌سازی شده را به عنوان متاکلاس‌های متامدل لحاظ کنیم. همانطور که در شکل 13 نشان داده شده است ، دیتاکیوب متاکلاس با سال سطح بعد و کشور سطح بعد به همان روشی که به سطح متاکلاس مرتبط است (در اینجا، متاکلاس های دیگر نشان داده نمی شوند) مرتبط است. از آنجایی که آنها نمونه هایی از سطوح بعدی هستند که بخشی از متامدل هستند، ما آنها را “سطوح فلزی” می نامیم. علاوه بر این، یک بعد شامل یک سطح فلزی، “متادیمنشن” نامیده می شود.

سطوح فلزی دقیقاً به همان روشی که سطوح نمونه در مدل‌های مکعب داده مدل‌سازی می‌شوند ( شکل 11 را در مقایسه با شکل 13 ببینید).). با این حال، آنها می توانند هم بخشی از مدل های متامدل و هم مدل های نمونه باشند. به عنوان مثال، در یک صورت فلکی شامل سال‌های 2018 و 2019، در مقایسه بین فرانسه و بلژیک از یک مکعب داده بلژیکی اختصاص داده شده به سال 2018، یک مکعب داده بلژیکی دیگر به سال 2019 و یک مکعب داده فرانسوی اختصاص داده شده به هر دو سال 2018 و 2019 استفاده می‌شود. از یک طرف. ، حقایق مکعب داده فرانسوی به اعضای سطح بعد “سال” (سطح مدل) مرتبط است. از سوی دیگر، حقایق مکعب‌های داده بلژیکی به سطح «سال» مرتبط نیستند، اما کل مکعب‌های داده به یکی از اعضای متالسطح «سال» (سطح متامدل) وابسته هستند. بنابراین، یک نقشه مرزی برای سال 2019 را می توان با یک عملیات برش در سال فلزی تولید کرد.هم در مدل و هم در متامدل. برای حل این مشکل، “year” متالول باید کلاسی باشد که هم متامدل ها و هم مدل های مکعب داده مشترک دارند. این ویژگی بولی is_meta را در سطح متاکلاس توضیح می دهد. در نهایت، لازم به ذکر است که تمام مکعب های داده باید حداقل به یک عضو متام کشور (یعنی فضا) و سال (یعنی زمان) مرتبط باشند.

6. پیاده سازی رابطه ای

این بخش پیاده سازی رابطه ای متامدل ما و بهره برداری SQL آن را از طریق یک مثال صورت فلکی شرح می دهد. بخش 6.1 متامالگوی منطقی استنتاج شده از فرامدل مفهومی را توصیف می کند. بخش 6.2 مثال صورت فلکی ذخیره شده در مدل منطقی را شرح می دهد. بخش 6.3 یک داستان کاربر SQL را توصیف می کند که شامل یک کاوش هوشمند در مثال صورت فلکی است.

6.1. متامدل منطقی

متامدل منطقی برنامه ما در شکل 14 نشان داده شده است . این بر اساس مدل مفهومی ارائه شده در بخش 5 است. این شامل دو سطح فرابعدی است: کشور و سال . در واقع، همانطور که قبلا توضیح داده شد، ابعاد داده ها در بلژیک و فرانسه متفاوت است و در زمان نیز تکامل می یابد. فرابعدها به ترتیب در روابط کشور و سال مدل شده اند. به دلیل ارتباط بسیار زیاد بین دیتاکیوب کلاس و متادیمنشن‌ها، اینها در جداول پل بسته به_کشور و بسته_سال پیاده‌سازی می‌شوند.. در واقع، یک مکعب داده می تواند به بلژیک، فرانسه یا هر دو کشور و همچنین می تواند به چندین سال بستگی داشته باشد (به عنوان مثال، بلژیک بین دو تعریف مجدد از کمون ها). سایر روابط و کلیدهای خارجی ناشی از تبدیل متامدل شکل 10 UML با تعاریف زیر از متاکلاس ها، انجمن ها و کاردینالیته ها هستند.

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

6.2. مثال صورت فلکی

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

فرمالیسم شکل 15 بر اساس قوانین زیر است:

مکعب داده (نمایش مکعب) مجموعه ای از حقایق است که احتمالاً بسته به استراتژی پیاده سازی (مکعب های ذخیره شده یا نه) در مکعب ها سازماندهی شده اند.
یک سطح (نمایش مستطیل) مجموعه ای از اعضای ابعاد است.
سطوح از یک بعد بر اساس رنگ گروه بندی می شوند.
سطوح فلزی (سطوح متعلق به یک فرابعد) با یک مستطیل دوتایی نشان داده می شوند.
فلش ها نشان دهنده ارتباط بین مکعب های داده و سطوح (ارتباط تجزیه و تحلیل_سطح در متامدل منطقی) و همچنین سلسله مراتب سطوح ابعاد است.
یک مکعب داده مرتبط با سطح دقیق ابعاد به طور ضمنی به سایر سطوح متصل مرتبط است (به عنوان مثال، مکعب داده BE_2018 به اندازه سطح مرتبط است و به طور ضمنی به سطح all_size مرتبط است ).
رتبه سطح به ویژگی level_rank متامدل اشاره دارد ( شکل 10 و شکل 14 ).

به منظور ساده نگه داشتن آن، مثال صورت فلکی یک زیرمجموعه زمانی محدود به سال‌های 2018 و 2019 است. همچنین فرض می‌کنیم که همه مکعب‌های داده نشان‌داده‌شده معیارهای یکسانی دارند (مثلاً تعداد شرکت‌ها).

این صورت فلکی چهار بعد را نشان می دهد: اندازه (یعنی اندازه شرکت)، فعالیت (یعنی حوزه فعالیت یک شرکت)، geoadmin (یعنی نهادهای اداری شامل سطوح جغرافیایی) و زمان . اندازه ابعاد دارای دو سطح است: یک اندازه سطح دقیق و یک سطح “همه” all_size . فعالیت ابعاد دارای سه سطح است: دو سطح دقیق موازی BE_activity و FR_activity ، به ترتیب برای بلژیک و فرانسه، و یک سطح “all” all_activity. از یک طرف ابعاد geoadminدارای سه سطح برای بلژیک است: دو سطح دقیق BE_commune_2018 و BE_commune_2019 ، به ترتیب برای سال های 2018 و 2019، و یک سطح برتر BE_ استان (شامل سال های 2018 و 2019). از سوی دیگر، ابعاد geoadmin برای فرانسه دارای دو سطح است: سطح تفصیلی FR_epci و سطح برتر FR_department. Dimension geoadmin همچنین شامل یک کشور سطحی است که مادر هر دو سطح BE_province و FR_department است. در نهایت زمان بعد یک سال سطح دارد. لازم به ذکر است که ابعاد geoadminو فعالیت طبق [ 35 ] سلسله مراتب موازی وابسته دارند.

این صورت فلکی همچنین شامل چهار مکعب داده است: BE_2018 (یعنی داده‌های بلژیکی برای سال 2018)، BE_2019 (یعنی داده‌های بلژیکی برای سال 2019)، FR_GEO1 (یعنی داده‌های فرانسوی برای سطح geoadmin FR_epci ) و FR_GEO2 (یعنی داده‌های فرانسوی برای geoadmin). سطح FR_department ). ارتباط‌های مختلف این مکعب‌های داده با سطوح ابعاد نمونه‌هایی از سه موضوع مربوط به تحلیل جغرافیایی است که شامل ابعاد ناهمگن است: تجزیه و تحلیل چند منطقه‌ای، تحلیل چند مقیاسی و تحلیل زمانی.

در رابطه با موضوع چند قلمرو، صورت فلکی آن بعد فعالیت را نشان می دهددارای سطوح جزئی خاص برای بلژیک و فرانسه است. بنابراین، مقایسه بین این دو کشور (به عنوان مثال، نقشه ای که استان های بلژیک و بخش های فرانسه را نشان می دهد) تنها با تجمیع اقدامات در سطح “همه” این بعد (که معادل نادیده گرفتن این بعد است) قابل انجام است. در واقع، مقایسه‌های بین مکعب‌های داده مختلف با جمع‌آوری ابعاد مشترک غیرمعمول در سطوح مشترک آنها، جمع‌آوری ابعاد غیرمعمول در سطح “همه” آنها و برش سطوح فلزی غیرنمایش‌نشده از فراابعاد بر روی اعضای مشترک آنها انجام می‌شود (این جنبه‌ها به تفصیل توضیح داده خواهد شد. در بخش بعدی). لازم به ذکر است که یک تجزیه و تحلیل شامل یک مکعب داده همچنان می تواند از تمام سطوح دقیق آن بهره مند شود (به عنوان مثال، سطح BE_activity برای مکعب داده BE_2018).

در رابطه با مسئله چند مقیاسی، صورت فلکی نشان می‌دهد که اندازه ابعاد به مکعب داده‌ها FR_GEO2، مرتبط با سطح FR_department ، متصل است، اما نه به مکعب داده‌ها FR_GEO1 ، مرتبط با سطح FR_epci (به دلیل محرمانه بودن آماری). با این حال، یک عملیات حفاری فضایی در بخش خاصی از مکعب داده FR_GEO2 همچنان می‌تواند داده‌های EPCI را از مکعب داده FR_GEO1 برای ناوبری صاف پیشنهاد کند، حتی اگر اندازه ابعاد در این فرآیند از بین برود.

با توجه به موضوع زمان، سال سطح بعد به عنوان یک سطح فلزی در نظر گرفته می شود (و بنابراین زمان بعد آن یک فرابعد است) زیرا یک کلاس متعلق به هر دو طرح صورت فلکی ( شکل 15 ) و فرامدل ( شکل 14 ) است. در واقع، علاوه بر ارتباط سال با مکعب های داده FR_GEO2 و FR_GEO1 در طرح صورت فلکی، مکعب های داده بلژیک BE_2018 و BE_2019به ترتیب در متامدل به متاممبرهای 2018 و 2019 بستگی دارد (به دلیل بازتعریف کمون های بلژیک در سال 2019). به لطف این مفهوم، نقشه ای که نشان دهنده کمون های بلژیک و EPCI فرانسه است را می توان به یک سال معمولی مانند 2018 تقسیم کرد. از یک طرف، حقایق 2018 در مکعب داده فرانسوی FR_GEO1 با یک عملیات برش کلاسیک در سال فلزی انتخاب می شوند . از سوی دیگر، مکعب داده بلژیکی برای سال 2018 در متامدل با استفاده از همان سال سطح فلزی مشترک بین دو مدل (صورت فلکی و متامدل) انتخاب شده است.

6.3. SQL کاوش صور فلکی

این بخش یک داستان کاربر را بر اساس مثال صورت فلکی شرح داده شده در بخش قبل توصیف می کند. از آنجایی که مدل متا مکعب داده ما در یک انبار داده رابطه ای پیاده سازی شده است، پرس و جوها در فرمالیسم SQL بسته به متامدل منطقی ارائه شده در بخش 6.1 توضیح داده می شوند . همانطور که قبلا توضیح داده شد، تمام مکعب های داده نمونه صورت فلکی اندازه های یکسانی دارند. بنابراین این جنبه در جستارهای زیر در نظر گرفته نمی شود. با این حال، معیارهای ناهمگن را می توان به سادگی با یک مشترک اضافی بین جداول اندازه گیری و تجزیه و تحلیل_میزان با یک شرط WHERE در معیار(های) مناسب برای در نظر گرفتن (مثلاً «تعداد شرکت ها») مدیریت کرد.

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

پرس و جو 1 مکعب های داده مربوط به سال 2018 و کشور فرانسه را نشان می دهد. نقطه شروع ناوبری کاربر است. از آنجایی که همه مکعب‌های داده مربوط به اعضای سال و کشور فرابعاد هستند ، کاربر این پارامترها را برای شروع ناوبری اصلاح می‌کند. به منظور ساده نگه داشتن آن، نتیجه پرس و جو در یک view datacube_FR_2018 ذخیره می شود که در جستارهای بعدی مجددا استفاده می شود. نتایج مکعب های داده FR_GEO1 و FR_GEO2 هستند. لازم به ذکر است که در مثال ما، تمام مکعب های داده فرانسوی مربوط به سال های 2018 و 2019 هستند.

ایجاد یا جایگزینی مشاهده datacube_FR_2018 AS
datacube_id، datacube_description را انتخاب کنید
از دیتاکیوب
پیوستن داخلی بسته_year در datacube.datacube_id=depending_year.datacube
پیوستن داخلی بسته_country در datacube.datacube_id=depending_country.datacube
AND metalevel_country=’FR’ AND metalevel_year=2018

پرس و جو 2 نتایج پرس و جو 1 را نشان می دهد که توسط مکعب های داده از جمله بعد “اندازه شرکت” فیلتر شده اند. در واقع، کاربر می خواهد تحلیل خود را بر روی این بعد خاص متمرکز کند. نتیجه مکعب داده FR_GEO2 است که با توضیحات “داده های فرانسوی در سطح بخش” مرتبط است.

DISTINCT datacube_id، datacube_description را انتخاب کنید
از datacube_FR_2018
پیوستن داخلی analyd_level ON analysisd_level.datacube=datacube_FR_2018.datacube_id
سطح JOIN داخلی ON level.level_id=analyzed_level.level
WHERE level.dimension=’size’

پرس و جو 3 اطلاعات اولیه در مورد ابعاد و سطوح مکعب داده FR_GEO2 را نشان می دهد . در واقع، کاربر این مکعب داده را برای کاوش انتخاب کرده است و این پارامترها توسط موتور SOLAP (از جمله معیارها، ویژگی‌های سطح و غیره) درخواست می‌شوند. نتایج پرس و جو در جدول 1 نشان داده شده است.

SELECT dimension_id، dimension_description، level_id، level_description، level_rank، is_all
از دیتاکیوب
پیوستن داخلی analyd_level ON analysisd_level.datacube=datacube.datacube_id
سطح JOIN داخلی ON level.level_id=analyzed_level.level
بعد JOIN داخلی ON dimension.dimension_id=level.dimension
WHERE datacube_id=’FR_GEO2′
ORDER BY dimension_id، level_rank

پرس و جو 4 مکعب های داده مربوط به فرانسه و سال 2018 را نشان می دهد (بعد ابعاد) که شامل سطح فرزند FR_department است. در واقع، کاربر یک تمرین فضایی را روی یکی از اعضای FR_department سطح جغرافیایی مرتبط با رتبه 1 انجام داده است ( جدول 1 را ببینید ). اگرچه سطح تفصیلی geoadmin برای مکعب داده FR_GEO2 است (هیچ سطح پایین‌تری برای geoadmin در جدول 1 وجود ندارد)، این سطح جزئی مطلق این بعد نیست (همانطور که قبلاً توضیح داده شد، سطوح جزئی مطلق دارای رتبه 0 هستند). مته فضایی پایینبنابراین عملیات توسط موتور SOLAP مجاز است که مکعب های داده مناسب را به متامدل درخواست می کند تا حفاری فضایی را انجام دهد . تنها نتیجه مکعب داده FR_GEO1 مرتبط با سطح FR_epci است. پس از آن، پارامترهای ناوبری SOLAP در مورد مکعب داده FR_GEO2 (مثلاً سطح نمایان شده ابعاد یا عضو تکه تکه شده) را می توان به سطوح بعدی معمولی FR_GEO1 ، یعنی سال و FR_activity ( شکل 15 را ببینید ) منتقل کرد. در نهایت، پارامترهای اولیه فراابعاد تغییر نکرده است (سال 2018 و کشور فرانسه).

datacube_id، datacube_description را انتخاب کنید
از datacube_FR_2018
INNER JOIN analyzed_level on datacube_FR_2018.datacube_id=analyzed_level.datacube
سطح JOIN داخلی در level.level_id=analyzed_level.level
سلسله مراتب JOIN داخلی در hierarchy.child=level.level_id
AND والد=’fr_department’

پرس و جو 5 مکعب های داده مربوط به بلژیک و سال 2018 (ابعاد متا) را نشان می دهد که شامل سطح دقیق مطلق (رتبه 0) ابعاد geoadmin است. در واقع، کاربر می‌خواهد بلژیک را به نقشه فرانسوی اضافه کند که سطح 0 ( FR_ epci) ابعاد geoadmin را نشان می‌دهد. بنابراین این سیستم مکعب های داده قابل مقایسه مربوط به عضو ‘BE’ کشور متالسطح را پیشنهاد می کند، به عنوان مثال، مکعب های داده شامل سطحی از همان رتبه برای geoadmin ابعاد نشان داده شده است . تنها نتیجه، مکعب داده BE_2018 است که با توضیحات “داده های بلژیکی برای سال 2018” مرتبط است که شامل سطح BE_commune_2018 است.

datacube_id، datacube_description را انتخاب کنید
از دیتاکیوب
پیوستن داخلی بسته_year ON datacube_id=depending_year.datacube
پیوستن داخلی بسته_country در datacube_id=depending_country.datacube
پیوستن داخلی analysisd_level در datacube_id=analyzed_level.datacube
سطح پیوستن داخلی ON analysisd_level.level=level.level_id
بعد JOIN داخلی ON level.dimension = dimension.dimension_id
WHERE datacube_id=depending_year.datacube
و datacube_id=depending_country.datacube
AND metalevel_country=’BE’ AND metalevel_year=2018
AND level_rank=0 AND dimension=’geoadmin’

پس از آن، مقایسه های جغرافیایی بین دو مکعب داده (به عنوان مثال، BE_2018 و FR_GEO1 ) را می توان با پیروی از این قوانین انجام داد:

سطوح جغرافیایی مقایسه شده دارای رتبه یکسانی هستند
ابعاد مشترک غیر نمایش داده شده را فقط می توان در سطوح مشترک آنها جمع کرد
ابعاد غیر معمول در سطح “همه” آنها جمع می شوند
فرابعدهای ارائه نشده توسط متاممبرهای رایج برش داده می شوند

قانون 1 قبلاً در پرس و جوی 5 گنجانده شده است. قوانین 2، 3 و 4 ابعاد جدیدی را تعریف می کنند که هر دو مکعب داده را برای مقایسه مشخص می کند. اینها به تفصیل در زیر آمده است.

پرس و جو 6 سطوح ابعاد مورد نیاز توسط قانون 2 را نشان می دهد. با تقاطع سطوح ابعاد مکعب داده بلژیکی با مکعب داده فرانسوی حل می شود. نتایج سطوح کشور (dimension geoadmin ) و all_activity (dimension activity ) هستند. بنابراین، اگر مقایسه یک نقشه فرامرزی باشد، geoadmin بعد نشان‌داده‌شده است که در سطح مقایسه جمع‌آوری می‌شود (رتبه 0 شامل EPCI فرانسه و کمون‌های بلژیک). از سوی دیگر، فعالیت بعد غیر نمایش داده شده باید در سطح all_activity مطابق نتایج جستجوی 6 جمع شود. در یک مثال پیچیده تر، ما می توانیم سطح واسطه ای از فعالیت ابعاد را تصور کنیمکه والد هر دو سطح BE_activity و FR_activity و فرزند سطح all_activity خواهد بود. این سطح، با گروه‌بندی مجدد فعالیت‌های فرانسه و بلژیک در گونه‌شناسی با جزئیات کمتر، در نتایج پرسش 6 گنجانده می‌شود. برای مثال، فیلتر کردن (یعنی برش) نقشه فرامرزی را بر اساس اعضای این نوع شناسی فراملی منطقه فعالیت امکان پذیر می کند. در نهایت باید توجه داشت که این کوئری سال سطح را برنمی‌گرداند زیرا به مکعب داده FR_GEO1 مرتبط است اما به مکعب داده BE_2018 مرتبط نیست. با این حال، به دلیل وضعیت آن به عنوان یک فلز، حداقل یک عضو در سال استبه طور ضمنی با تمام مکعب های داده مرتبط است. در نتیجه، در همه مقایسه‌ها ، تجمیع‌ها در سال فلزی (و همچنین کشور سطح فلزی) مجاز هستند.

SELECT dimension_id، level_id
از بعد
سطح JOIN داخلی در ابعاد = dimension_id
INNER JOIN analysed_level در سطح = level_id
دیتاکیوب JOIN داخلی در datacube=datacube_id
WHERE datacube_id=’BE_2018′
تقاطع
SELECT dimension_id، level_id
از بعد
سطح JOIN داخلی در ابعاد = dimension_id
INNER JOIN analysed_level در سطح = level_id
دیتاکیوب JOIN داخلی در datacube=datacube_id
WHERE datacube_id=’FR_GEO1′

پرس و جو 7 ابعاد غیرمتداول مکعب های داده فرانسوی و بلژیکی را طبق قانون 3 نشان می دهد. تفاوت متقارن بین مجموعه ابعاد مربوط به این دو مکعب داده را اعمال می کند. نتیجه اندازه ابعاد است که فقط به مکعب داده بلژیکی مرتبط است. بنابراین، مکعب داده BE_2018 همیشه باید در سطح all_size در این مقایسه جمع شود. طبق قانون 3، بنابراین هر بعد باید شامل یک سطح “همه” باشد. با این حال، این به فرابعدها مربوط نمی شود زیرا آنها به طور ضمنی با تمام مکعب های داده در تعریف مرتبط هستند. به همین دلیل، پرس و جو شامل یک شرط “is_meta=false” است.

DISTINCT dimension_id را انتخاب کنید
از بعد
سطح JOIN داخلی در ابعاد = dimension_id
INNER JOIN analysed_level در سطح = level_id
دیتاکیوب JOIN داخلی در datacube=datacube_id
WHERE datacube_id=’BE_2018′ و is_meta=false است
تفاوت متقارن
DISTINCT dimension_id را انتخاب کنید
از بعد
سطح JOIN داخلی در ابعاد = dimension_id
INNER JOIN analysed_level در سطح = level_id
دیتاکیوب JOIN داخلی در datacube=datacube_id
WHERE datacube_id=’FR_GEO1′ و is_meta=false است

لازم به ذکر است که SQL استاندارد شامل تابع تفاوت متقارن نمی شود. به جای “A متقارن تفاوت B”، پرس و جو باید “(A متمایز شده توسط B) اتحادیه (B متمایز شده توسط A)” باشد. بسته به سیستم مدیریت پایگاه داده مورد استفاده، “متمایز شده توسط” “به جز” یا “منهای” نامیده می شود. با این حال، هر دو پرس و جو 6 و 7 باید توسط موتور SOLAP به جای متامدل به دلایل عملکرد واضح انجام شوند. در واقع، قوانین 2 و 3 را می توان مستقیماً از ابرداده های چند بعدی مربوط به مکعب های داده بلژیکی و فرانسوی (که می تواند با پرس و جوهایی مشابه پرس و جو 3 برگردانده شود) استنتاج کرد. با این وجود، داستان کاربری ما همچنان می تواند با استفاده از همان الگوی SQL توصیف شود.

در نهایت، پرس و جو 8 اعضای برش خورده سال فلزی را مطابق قانون 4 نشان می دهد. با تقاطع متامبرهای مربوط به مکعب داده بلژیکی با متامبرهای مربوط به مکعب داده فرانسوی حل می شود. تنها نتیجه عضویت “2018” است. در واقع، مکعب داده بلژیکی فقط مربوط به سال 2018 و مکعب داده فرانسوی مربوط به هر دو سال 2018 و 2019 است. در نتیجه، مکعب داده FR_GEO1 باید همیشه تا سال 2018 برش داده شود تا نقشه فرامرزی ثابت بماند.

SELECT Member_id
از سال
پیوستن داخلی بستگی_سال به metalevel_year=member_id
دیتاکیوب JOIN داخلی در datacube_id=datacube
WHERE datacube_id=’FR_GEO1′
تقاطع
SELECT Member_id
از سال
پیوستن داخلی بستگی_سال به metalevel_year=member_id
دیتاکیوب JOIN داخلی در datacube_id=datacube
WHERE datacube_id=’BE_2018′

7. اعتبار سنجی

متامدل پیشنهادی این تحقیق توسط پلتفرم وب “راسینز” [ 59 ] تایید شده است. معماری کلی آن ( بخش 7.1 ) و همچنین سه ماژول اصلی آن ارائه شده است: ماژول مدیریت مکعب داده ( بخش 7.2 )، ماژول SOLAP ( بخش 7.3 ) و ماژول گزارش ( بخش 7.4 ). بخش 7.5 تجربه محصول را از دیدگاه مدیران و کاربران نهایی مورد بحث قرار می دهد.

7.1. معماری کلی

معماری Racines کاملا متن باز است. این عمدتا بر اساس یک انبار داده رابطه ای PostgreSQL است. این ابزار متامدل مکعب داده و همچنین صورت فلکی مکعب داده را از طریق کوئری های SQL در طرحواره های مختلف مدیریت می کند. به لطف پسوند PostGIS PostgreSQL می توان ابعاد جغرافیایی را طبق استاندارد OGC [ 16 ] فضایی کرد.

همانطور که در شکل 16 نشان داده شده است ، ماژول های دیگر به انبار داده بستگی دارند. در ماژول مدیریت مکعب داده، مدیران صورت فلکی مکعب داده را تعریف کرده و داده های از پیش پردازش شده را به DW وارد می کنند. منظور ما از “پیش پردازش” داده هایی است که قبلاً ساختاری چند بعدی دارند که احتمالاً توسط یک ابزار ETL تبدیل شده است. کاربران نهایی می توانند داده ها را در ماژول های SOLAP و گزارش کاوش و تجزیه و تحلیل کنند. اینها به لطف یک موتور SOLAP که با مدل متا و مکعب های داده ذخیره شده در DW ارتباط برقرار می کند، عملیات SOLAP را در رابط های کاربر پسند مدیریت می کنند.

7.2. ماژول مدیریت مکعب های داده

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

هر عملیات مربوط به یک کلاس از متامدل مکعب داده است ( شکل 10 را ببینید ). اینها به تفصیل در زیر آمده است.

ایجاد اندازه : اندازه‌گیری‌ها با تعریف پارامترهای مورد نیاز متامدل مانند اندازه‌گیری ، نوع ، اندازه_توصیف و غیره ایجاد می‌شوند .
ایجاد ابعاد : ابعاد با تعریف پارامترهای dimension_id و dimension_description ایجاد می شوند.
ایجاد ویژگی سطح : ویژگی ها با تعریف پارامترهای attribute_id ، type و attribute_description ایجاد می شوند.
ایجاد سطح جغرافیایی: سطوح جغرافیایی ابعاد بر اساس یک فایل GeoJSON (نشان‌گذاری شی جاوا اسکریپت جغرافیایی) شامل شناسه‌های اعضا، توضیحات اعضا (مثلاً نام کمون‌های بلژیک)، هندسه‌های اعضا بر اساس [ 16 ]، شناسه‌های اعضای سطح برتر قبلاً ایجاد می‌شوند. ایجاد شده (به عنوان مثال، استان بلژیک) و هر ویژگی دیگری که قبلاً در مرحله 3 ایجاد شده است (به عنوان مثال، جمعیت یک کمون). علاوه بر این، مدیر سیستم مرجع مختصات را در پارامتر srid با توجه به کلاس geographic_level متامدل تعریف می کند. پارامترهای entity_type و spatial_attributeدر Racines مورد نیاز نیست زیرا سطوح جغرافیایی همیشه شامل چند ضلعی های تعریف شده در یک ویژگی فضایی PostGIS به نام “geom” است. در نهایت، مدیر تمام پارامترهای متعلق به سطح کلاس متامدل ( level_id ، level_rank و غیره) و همچنین بعد سطحی که قبلا در مرحله 2 تعریف شده بود را تعریف می کند.
ایجاد سطح: بر اساس یک فایل CSV (مقادیر جدا شده با کاما) حاوی داده های مکعبی، یک سطح غیرجغرافیایی را می توان به روشی مشابه مرحله 4 بدون جنبه مکانی ایجاد کرد.
ایجاد مکعب داده: در نهایت، یک مکعب داده می‌تواند ایجاد شود که تمام اندازه‌ها و سطوح ابعاد آن قبلاً در DW ذخیره شده باشد (به یاد داشته باشید که مکعب‌های داده می‌توانند سطوح ابعاد و اندازه‌های مشترک را برای ذخیره صور فلکی در DW به اشتراک بگذارند). پس از تعریف پارامترهای datacube_id ، datacube_description و متامبرهای فرابعدی مرتبط (کشور و سال)، داده‌های مربوط به مکعب‌ها از یک فایل CSV وارد می‌شوند.

ماژول مدیریت مکعب داده همچنین امکان ادغام مکعب های داده از جمله سطح ابعاد غیر معمول را در صورت امکان فراهم می کند. در واقع، بعد «منطقه فعالیت» در بلژیک و فرانسه گونه‌شناسی متفاوتی دارد. بلژیک دارای 20 دسته است در حالی که فرانسه دارای 8 دسته است. در عملیات ادغام، حقایق بلژیکی مرتبط با این بعد به طور خودکار بر اساس جدول جستجوی تعریف شده توسط مدیر جمع می شوند. برای مثال، حقایق مربوط به مقوله‌های بلژیکی «آموزش ابتدایی» و «آموزش متوسطه» را می‌توان با یک دسته فرانسوی «آموزش» ادغام کرد. بر اساس این مکعب داده جدید ایجاد شده مربوط به هر دو عضو بلژیک و فرانسه، نقشه های مرزی برش شده توسط “آموزش” را می توان توسط ماژول SOLAP تولید کرد.

7.3. ماژول SOLAP

ماژول SOLAP برای هر کاربری در دسترس است. این امکان کاوش رایگان مکعب های داده ایجاد شده در ماژول مدیریت مکعب داده را فراهم می کند. اینها بر اساس سال، کشور و سطح جغرافیایی گروه بندی می شوند. هنگامی که یک مکعب داده انتخاب شد، عملیات SOLAP را می توان بر روی یک رابط نقشه انجام داد که سطوح جغرافیایی ابعاد را نشان می دهد ( شکل 18 را ببینید ). بسته به انتخاب کاربر، موجودیت های جغرافیایی را می توان با روش خطی یا پنجکی برای نمادسازی آنها طبقه بندی کرد. رابط نقشه پویا به زبان جاوا اسکریپت برنامه ریزی شده است و عمدتا بر اساس کتابخانه OpenLayers است. بسته به درخواست های SOLAP، لایه های نقشه با فرمت GeoJSON توسط موتور SOLAP (سمت سرور) ارسال می شوند.

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

در زمان نگارش این مقاله، داده های موجود از ماژول SOLAP به این موارد مربوط می شود:

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

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

علاوه بر تجسم و معیارهای فضایی مشتق شده (به عنوان مثال، شرکت ها در هر کیلومتر مربع)، هندسه های متصل به ابعاد جغرافیایی نیز می توانند تجزیه و تحلیل فضایی را به OLAP بیاورند. بنابراین، سایر عملکردهای فضایی در به روز رسانی های آینده ماژول SOLAP برنامه ریزی شده است. به طور خاص، متخصصان اقتصاد اجتماعی علاقه مند به برش مکعب های داده های جغرافیایی بر اساس روابط فضایی بین اعضای جغرافیایی ابعاد هستند. به عنوان مثال، یک تحلیل چند بعدی می تواند بر یک کمون خاص و همسایگان مجاور آن تمرکز کند. علاوه بر این، لایه‌های فضایی خارجی می‌توانند ابعاد جغرافیایی را به صورت فضایی قطع کنند و در نتیجه اعضای جدید و حقایق فضایی انباشته‌شده جدیدی ایجاد کنند [ 17 ، 19 ]]. به عنوان مثال، کاربران نهایی می توانند مناطق استخدامی را در SOLAP وارد کنند تا حقایق مربوط به کمون های متقاطع را جمع آوری کنند (در صورتی که چنین تجمیع هایی با توجه به محرمانه بودن آماری امکان پذیر باشد). این عملیات را می توان در موتور SOLAP ما به لطف SQL فضایی ارائه شده توسط PostGIS پیاده سازی کرد.

7.4. ماژول گزارش

ماژول گزارش نیز برای هر کاربری در دسترس است. برخلاف SOLAP، اکتشاف محدود به انتخاب یک نهاد اداری از طریق یک منوی درختی است که سلسله مراتب ابعاد جغرافیایی را نشان می‌دهد ( شکل 19 a را ببینید). پس از آن، سیستم یک گزارش کامل در مورد نهاد انتخاب شده برای آخرین سال موجود در DW تولید می کند ( شکل 19 ب را ببینید).

گزارش با یک زمینه کلی شامل اطلاعات مرتبط در مورد نهاد انتخاب شده مانند:

جمعیت (ویژگی سطح بعد)،
تراکم جمعیت ( idem )
تعداد کل شرکت ها، کارفرمایان و کل حقوق و دستمزد (معیارهای مکعب داده)،
نقشه‌هایی که تعداد شرکت‌ها و کارگران را برای واحدهای هم سطح متعلق به نهاد اداری سطح برتر نشان می‌دهد، به عنوان مثال، تمام استان‌های متعلق به منطقه بلژیک “والونی” در صورت انتخاب استان “لیژ” ( مجموعه فضایی ).

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

از آنجایی که آنها بر اساس متامدل مکعب داده هستند، گزارش‌های سالانه به‌طور خودکار زمانی که داده‌های جدیدتر توسط مدیران یکپارچه می‌شوند، به‌روزرسانی می‌شوند. با این وجود، تحولات معنایی مهم داده‌ها می‌تواند به مهارت‌های برنامه‌نویسی نیاز داشته باشد زیرا برخی از نمایش داده‌های ماژول گزارش‌دهی به ابعاد و/یا اعضای ابعاد بسیار خاص بستگی دارد. ماژول SOLAP تحت تأثیر این مشکل قرار نمی گیرد.

7.5. تجربه محصول

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

مدیران متخصصان اقتصاد اجتماعی هستند که قبلاً برای تجزیه و تحلیل داده های چند بعدی ذخیره شده در فایل های MS Excel استفاده می کردند. در نتیجه، تخصیص مفاهیم اصلی OLAP یک مسئله واقعی نبود، زیرا واژگان OLAP به راحتی قابل انتقال به حوزه اقتصاد اجتماعی بود. به عنوان مثال، «مکعب داده» در واقع به عنوان «مجموعه داده»، «حقایق» به عنوان «داده»، «اندازه گیری» به عنوان «شاخص» یا «ابعاد» به عنوان «معیار متقاطع» شناسایی شدند. مفهوم دشوارتر، اشتراک سطوح بعد در صورت فلکی بود. در واقع، پس از تحویل به خود، برخی از مدیران تمایل به ایجاد سطوح جدید به جای مرتبط کردن سطوح مشابه معنایی ذخیره شده در DW داشتند. در واقع، از آنجایی که اعضای بعد همیشه با شناسه های منحصر به فرد در داده های ورودی مشخص نمی شوند (به عنوان مثال، خانواده اقتصاد اجتماعی)، این سیستم به ارتباط دستی اعضایی نیاز دارد که شرح آنها دقیقاً با اعضای حاضر در DW مطابقت ندارد. برای حفظ ناوبری ثابت صورت فلکی، لازم بود در یک آموزش سه ساعته که به ادغام داده ها در راسینز اختصاص داده شده بود، بر این جنبه پافشاری شود. با این حال، ادغام خودکار سطوح ابعاد را می توان با پردازش زبان طبیعی (NLP) بهبود بخشید.60 ].

سایر مشکلات مربوط به مدیریت راسینز در پیش پردازش داده های مکانی توسط GIS مواجه شد. در واقع، Racines به فایل‌های GeoJSON به عنوان ورودی برای ایجاد سطوح جغرافیایی ابعاد نیاز دارد. بنابراین یک آموزش سه ساعته دیگر به ساخت فایل های GeoJSON با استفاده از ابزار QGIS اختصاص یافت. بر اساس شکل فایل‌های ESRI و فایل‌های اکسل، چند فرآیند GIS خاص مانند بازپرداخت داده‌ها در سیستم مرجع مختصات WGS84، اتصالات مبتنی بر ویژگی، تقاطع‌های فضایی و تجمع‌های فضایی توسط اتحاد را شامل می‌شود. در واقع، EPCI فرانسه اساساً گروه‌هایی از کمون‌ها هستند که احتمالاً هر سال تغییر می‌کنند. با این حال، هندسه‌های EPCI همیشه توسط ارائه‌دهندگان ملی داده‌های مکانی پیشنهاد نمی‌شوند و بنابراین لازم است آنها را بر اساس تعریف معنایی آن‌ها، یعنی فهرستی از شناسه‌های کمون، ایجاد کنیم.

از دیدگاه کاربر نهایی، راسینز هنوز برای ارزیابی کامل در مورد اقتصاد اجتماعی بسیار جوان است. از آنجایی که تقریباً به هیچ اقدامی از جانب کاربران نیاز ندارد، ما معتقدیم که ماژول گزارش‌دهی یک پشتیبانی عالی برای هر کسی است که به تجزیه و تحلیل سریع داده‌های مربوط به یک منطقه خاص نیاز دارد. از سوی دیگر، ماژول SOLAP امکانات بسیار بیشتری را برای کاربرانی که آماده اند زمان بیشتری را برای تجزیه و تحلیل و آشنایی با عملیات اصلی OLAP (برش، رول کردن، دریل کردن و غیره) صرف کنند، ارائه می دهد. در واقع، کاوش داده های ارائه شده توسط SOLAP اغلب به چندین عملیات قبل از یافتن همبستگی های جالب نیاز دارد. به همین دلیل، زمان اجرای پرس و جو قرار نیست از چند ثانیه تجاوز کند [ 61 ].

با توجه به استانداردهای عملکرد، موتور Racines ROLAP نتایج خوبی را ارائه می دهد زیرا عملیات SOLAP برای بازگشت داده ها از 1 یا 2 ثانیه تجاوز نمی کند. این زمان‌های اجرا شامل پرس‌وجو چند بعدی از مکعب(های) داده (احتمالاً دو مکعب داده در صورتی که بلژیک و فرانسه هر دو درگیر عملیات درگیر باشند) و ارسال نتایج JSON به مرورگر است. در حال حاضر، بزرگترین مکعب داده Racines DW دارای 99050 واقعیت است که در مقایسه با سایر پروژه های BI که با میلیاردها واقعیت سروکار دارند، نسبتاً کوچک است [ 61 ].]. در واقع، تنها مشکل عملکرد در تبدیل حقایق جغرافیایی به فرمت GeoJSON توسط PostGIS DW (چند ثانیه) بود. ما با ذخیره سطوح ابعاد جغرافیایی به عنوان فایل‌های GeoJSON در سرور و درخواست از مشتری جاوا اسکریپت برای پیوستن به آنها با حقایق بازگردانده شده توسط SOLAP (بر اساس شناسه اعضا) نتایج بسیار بهتری داریم. با این وجود، ما هنوز باید هندسه های PostGIS را ذخیره کنیم تا پتانسیل تجزیه و تحلیل فضایی راسینز را از دست ندهیم، که متأسفانه زائد است. در نهایت، انتخاب مکعب های داده در صورت فلکی بسیار سریع است (حدود 50 میلی ثانیه) زیرا راسینز در حال حاضر تنها 50 مکعب داده را ذخیره می کند (قرار نیست این تعداد در سال های آینده از چند صد نفر تجاوز کند). یک تست عملکرد واقعی که شامل مکعب های داده بیشتر و کشورهای بیشتری برای مقایسه می شود، دیدگاه جالبی را ارائه می دهد.

8. نتیجه گیری

این تحقیق با هدف توسعه یک ابزار هوش تجاری که با سه موضوع مهم تحلیل جغرافیایی مرتبط با داده‌های ناهمگن و چند بعدی سروکار دارد: تحلیل چند مقیاسی (یعنی تغییرات ابعاد بسته به مقیاس)، تحلیل چند قلمرو (یعنی تغییر ابعاد بسته به قلمرو) و تحلیل زمان (یعنی بعد بسته به زمان تغییر می کند). این ابزار باید برای یک مطالعه موردی اقتصاد اجتماعی طراحی می‌شد که با این سه موضوع مواجه است و نیاز به استقلال کاربر در مورد کاوش و ادغام داده‌ها دارد.

بر اساس بررسی ادبیات مربوط به جغرافیای اقتصادی، هوش تجاری، (S)OLAP و به ویژه جنبه های مدل سازی آن (مربوط به سه موضوع تحلیل جغرافیایی)، ما این فرضیه را برای رسیدن به هدف تحقیق خود فرموله کردیم: طراحی UML. متامدل قادر به نمونه‌سازی مکعب‌های داده‌های مکانی با سطوح ابعاد مشترک است. در واقع، متامدل‌های مکعب داده می‌توانند هم برای ادغام آسان داده‌های ناهمگن و هم برای ناوبری SOLAP در صورت فلکی پیچیده از مکعب‌های داده استفاده شوند.

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

پس از آن، ما یک پیاده‌سازی رابطه‌ای از متامدل و بهره‌برداری SQL آن را بر اساس یک مثال صورت فلکی با الهام از مطالعه موردی اقتصاد اجتماعی ارائه کردیم. بنابراین، ما ناوبری هوشمند را در صورت فلکی مکعب داده از طریق عملیات فضایی “دریل کردن” یا “رول کردن” و همچنین مقایسه مکعب های داده از طریق نقشه های بین مرزی ثابت نشان دادیم.

در نهایت، این متامدل توسط یک پلتفرم وب عملیاتی به نام «راسینز» که برای متخصصان اقتصاد اجتماعی توسعه یافته بود، تأیید شد. “راسینز” اجازه می دهد تا یکپارچه سازی و تجزیه و تحلیل کارآمد مجموعه داده های چند بعدی در مورد اقتصاد اجتماعی در فرانسه و بلژیک را از طریق سه ماژول مختلف انجام دهد:

یک ماژول مدیریت مکعب داده برای ادغام آسان داده های ناهمگن در صورت فلکی مکعب داده.
یک ماژول SOLAP برای اکتشاف داده ها در نقشه های پویا (از جمله نقشه های فرامرزی) و نمودارها.
یک ماژول گزارش که نمایش ایستا از داده ها را بسته به نهادهای اداری سلسله مراتبی نشان می دهد.

متامدل طراحی شده برای این تحقیق مدیریت کارآمد داده های ناهمگن را با توجه به ادغام و کاوش آنها در SOLAP نشان می دهد. در مقایسه با سایر متامدل‌های SOLAP، به کاربران نهایی اجازه می‌دهد تا صور فلکی پیچیده را از طریق حفاری فضایی بین ستاره‌ای و رول کردن فضایی در حالی که با ابعاد وابسته به مقیاس سازگار هستند، کاوش کنند. همچنین امکان مقایسه مکانی-زمانی مکعب های داده که با ابعاد وابسته به زمان و قلمرو مشخص می شود را فراهم می کند. علاوه بر این، کاوش داده‌ها بصری باقی می‌ماند، زیرا فقط شامل چند بعد است که احتمالاً می‌تواند سلسله مراتب چندگانه و موازی را طبق [ 35 ] جمع‌آوری کند.]. در واقع، پارامتر “level_rank” متامدل اختیاری است زیرا برای محدود کردن مقایسه‌های مکعب‌های داده با مواردی که توسط متخصصان اقتصاد اجتماعی مرتبط تلقی می‌شوند، معرفی شد.

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

برای هدف همکاری، ما به وضوح متامدل را از مکعب های داده نمونه جدا کردیم. این درها را به روی استراتژی های مختلف پیاده سازی سازگار با این جنبه های مختلف باز می کند. برای مثال، مکعب‌های داده را می‌توان توسط پایگاه‌های داده آرایه‌ای (MOLAP) یا پایگاه‌های داده رابطه‌ای (ROLAP) مدیریت کرد، در حالی که تعاریف صورت فلکی را می‌توان با ذخیره‌سازی اسناد یا نمودارهای RDF برای جلوگیری از اتصالات متعدد مدیریت کرد. در مورد خودکارسازی یکپارچه سازی داده ها، شایان ذکر است که صورت فلکی گراف RDF می تواند به راحتی به سایر داده های باز وب معنایی متصل شود.

منابع

فرانکلین، سی. Hane, P. مقدمه ای بر سیستم های اطلاعات جغرافیایی: پیوند نقشه ها به پایگاه های داده و نقشه ها برای بقیه: مقرون به صرفه و سرگرم کننده. پایگاه داده 1992 ، 15 ، 12-15. [ Google Scholar ]
Castells, M. The Rise of the Network Society , 2nd ed.; Wiley-Blackwell: Chichester، UK; Malden، MA، ایالات متحده آمریکا، 2010. [ Google Scholar ]
تر وال، آل. بوشما، RA بکارگیری تحلیل شبکه های اجتماعی در جغرافیای اقتصادی: چارچوب بندی برخی مسائل تحلیلی کلیدی. ان Reg. علمی 2009 ، 43 ، 739-756. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
گلوکلر، جی. دوریان، ص. تحریریه: تحلیل شبکه های اجتماعی و جغرافیای اقتصادی – رویکردهای موقعیتی، تکاملی و چند سطحی. جی. اکون. Geogr. 2016 . [ Google Scholar ] [ CrossRef ]
جونز، ا. مورفی، JT عمل نظریه پردازی در جغرافیای اقتصادی: مبانی، چالش ها و امکانات. Prog. هوم Geogr. 2011 ، 35 ، 366-392. [ Google Scholar ] [ CrossRef ]
بوشما، RA; Martin, R. (Eds.) The Handbook of Evolutionary Economic Geography ; ادوارد الگار: چلتنهام، بریتانیا؛ Northampton، MA، ایالات متحده، 2010. [ Google Scholar ]
باتلت، اچ. گلوکلر، جی. طراحی تحقیقات رابطه‌ای در جغرافیای اقتصادی . انتشارات دانشگاه آکسفورد: آکسفورد، انگلستان، 2018; جلد 1. [ Google Scholar ]
نگار، س. گری، پی. هوش تجاری. در کتابچه راهنمای پشتیبانی تصمیم. سیستم های 2 ; Springer: برلین/هایدلبرگ، آلمان، 2008; صص 175-193. [ Google Scholar ]
بدارد، ت. دوبه، ای. دیالو، بی. متیو، جی. Ouattara، M. منبع باز اطلاعات مکانی تجاری مکانی (BI) در عمل، ارائه شده در OGRS، نانت. 2009. در دسترس آنلاین: https://docplayer.net/10340377-Open-source-geospatial-business-intelligence-bi-in-action.html (دسترسی در 20 نوامبر 2019).
کاتال، ا. وزیر، م. گودار، RH داده های بزرگ: مسائل، چالش ها، ابزارها و شیوه های خوب. در مجموعه مقالات ششمین کنفرانس بین المللی محاسبات معاصر 2013 (IC3)، نویدا، هند، 8 تا 10 اوت 2013. ص 404-409. [ Google Scholar ] [ CrossRef ]
کیمبال، آر. Ross, M. The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling , 3rd ed.; John Wiley & Sons, Inc.: Indianapolis, IN, USA, 2013. [ Google Scholar ]
پرولکس، ام.-جی. Bédard, Y. Comparaison de L’Approche Transactionnelle des SIG Avec L’ Approche Multidimensionnelle pour L’Analyse de Données Spatio-Temporelles’. ارائه شده در Colloque Géomatique 2004—Un Choix Stratégique! مونترال، QC، کانادا، 27-28 اکتبر 2004. در دسترس آنلاین: https://yvanbedard.scg.ulaval.ca/wp-content/documents/publications/359.pdf (دسترسی در 30 نوامبر 2020).
گائو، بی. ژانگ، اس. Yao, N. یک مدل جدول محوری چند بعدی بر اساس الگوی MVVM برای برنامه های اینترنتی غنی. در مجموعه مقالات سمپوزیوم بین المللی 2012 کامپیوتر، مصرف کننده و کنترل، تایچونگ، تایوان، 4 تا 6 ژوئن 2012. ص 24-27. [ Google Scholar ] [ CrossRef ]
Aufaure, M.-A.; کوچمن-بوگر، ن. مارسل، پی. ریزی، اس. Vanrompay، Y. پیش‌بینی درخواست OLAP بعدی خود بر اساس جلسات تحلیلی اخیر. در انبار داده و کشف دانش ; Bellatreche, L., Mohania, MK, Eds. Springer: برلین/هایدلبرگ، آلمان، 2013; جلد 8057، صص 134–145. [ Google Scholar ]
Bédard، Y.; هان، جی. مبانی ذخیره‌سازی داده‌های مکانی برای کشف دانش جغرافیایی. در داده کاوی جغرافیایی و نسخه کشف دانش ، ویرایش دوم. Chapman & Hall/CRC: Boca Raton، FL، USA، 2009; صص 45-67. [ Google Scholar ]
Open Geospatial Consortium Inc. OpenGIS ^® Standard Implementation Information Geographic—Simple Feature Access—Part 1: Common Architecture. جان، آر. هرینگ. 28 مه 2011. موجود به صورت آنلاین: https://www.ogc.org/standards/sfa (دسترسی در 20 نوامبر 2006).
بیمونته، اس. چونیکین، آ. میکل، ام. Pinet، F. هنگامی که تحلیل فضایی با OLAP: مدل و عملگرهای چند بعدی ملاقات می کند. بین المللی J. Data Warehous. حداقل 2010 ، 6 ، 33-60. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
Bimonte, S. Intégration de L’information Géographique dans les Entrepôts de Données et L’analyse en Ligne: De la Modélisation à la Visualisation. دکتری پایان نامه، Institut National des Sciences Appliquées de Lyon، Villeurbanne، فرانسه، 2007. [ Google Scholar ]
کاسپرژیک، جی.-پی. دانی، جی.-پی. یک SOLAP رستر برای تجسم فیلدهای داده جرم. در GEOProcessing 2016 ; IARIA: ونیز، ایتالیا، 2016; صص 109-117. [ Google Scholar ]
کاسپرژیک، جی.-پی. دانی، جی.-پی. یک SOLAP شطرنجی که برای خدمات اضطراری مجتمع بروکسل طراحی شده است. در محاسبات ابری 2017 ؛ IARIA: آتن، یونان، 2017; صص 32-38. [ Google Scholar ]
وایسمن، ا. Zimányi, E. Mobility انبارهای داده. IJGI 2019 ، 8 ، 170. [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
میکل، ام. Bédard، Y.; Brisebois، A. Conception d’entrepôts de données géospatiales à partir de sources hétérogènes Exemple d’application en foresterie. ISI 2002 ، 7 ، 89-111. [ Google Scholar ] [ CrossRef ]
روشا، جنرال موتورز; Capelo، PL; Ciferri، CDA Healthcare تصمیم گیری بر روی انبار داده های جغرافیایی، اجتماعی-اقتصادی و تصویر. در کارگاه های مشترک و کنسرسیوم دکتری ADBIS، TPDL و EDA 2020 ؛ Bellatreche, L., Bieliková, M., Boussaïd, O., Catania, B., Darmont, J., Demidova, E., Duchateau, F., Hall, M., Merčun, T., Eds.; انتشارات بین المللی Springer: Cham، سوئیس، 2020; جلد 1260، ص 85–97. [ Google Scholar ]
آگاپیتو، جی. زوکو، سی. Cannataro، M. COVID-warehouse: انبار داده ای از داده های کووید-19 ایتالیا، آلودگی و آب و هوا. بین المللی جی. محیط زیست. Res. بهداشت عمومی 2020 ، 17 ، 5596. [ Google Scholar ] [ CrossRef ]
بیمونته، اس. کانگ، M.-A. به سمت مدلی برای تحلیل چند بعدی داده های میدانی. در پیشرفت در پایگاه های داده و سیستم های اطلاعاتی ; Catania, B., Ivanović, M., Thalheim, B., Eds.; Springer: برلین/هایدلبرگ، آلمان، 2010; جلد 6295، صص 58–72. [ Google Scholar ]
واسیلیادیس، پ. سلیس، تی. بررسی مدل های منطقی برای پایگاه های داده OLAP. SIGMOD Rec. 1999 ، 28 ، 64-69. [ Google Scholar ] [ CrossRef ]
پنتاهو، موندریان. 2017. در دسترس آنلاین: https://mondrian.pentaho.com/documentation/olap.php (در 21 نوامبر 2020 قابل دسترسی است).
مایکروسافت، PowerBI. 2020. در دسترس آنلاین: https://powerbi.microsoft.com (در 1 دسامبر 2020 قابل دسترسی است).
PostGIS. 2020. در دسترس آنلاین: https://postgis.net (در 1 دسامبر 2020 قابل دسترسی است).
فرو، م. فراگوسو، آر. فیدالگو، آر. انبار داده های مکانی مبتنی بر سند: ارزیابی تجربی پرس و جوهای SOLAP. در مجموعه مقالات بیست و یکمین کنفرانس IEEE در انفورماتیک تجاری (CBI) 2019، مسکو، روسیه، 15 تا 17 ژوئیه 2019؛ صص 47-56. [ Google Scholar ] [ CrossRef ]
Scabora، LC; بریتو، جی جی. Ciferri، RR; Ciferri، CDD طراحی انبار داده فیزیکی بر روی پایگاه های داده NoSQL – پردازش پرس و جو OLAP از طریق HBase. در مجموعه مقالات هجدهمین کنفرانس بین المللی سیستم های اطلاعات سازمانی، رم، ایتالیا، 25-28 آوریل 2016; صص 111-118. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
گور، ن. پدرسن، سل؛ شیلنگ، K. Midtgaard، M. غنی سازی چند بعدی داده های RDF فضایی برای SOLAP-نسخه کامل. arXiv 2020 ، arXiv:2002.06608. [ Google Scholar ]
لیت، DFB؛ Baptista، CDS; Amorim، BDSP یک ابزار SOLAP اکتشافی برای داده‌های باز مرتبط. IJBIS 2019 ، 31 ، 391. [ Google Scholar ] [ CrossRef ]
بریتو، جی جی. Siqueira، TLL; تایمز، وی سی. Ciferri، RR; د سیفری، سی‌دی پردازش کارآمد پرس‌و‌جوهای مته روی انبارهای داده‌های جغرافیایی. در انبار داده و کشف دانش ; Cuzzocrea, A., Dayal, U., Eds.; Springer: برلین/هایدلبرگ، آلمان، 2011; جلد 6862، صص 152–166. [ Google Scholar ]
مالینوفسکی، ای. Zimányi، E. سلسله مراتب OLAP: دیدگاه مفهومی. در کنترل جریان فعال و احتراق. 2018 ; King, R., Ed. Springer International Publishing: Cham, Switzerland, 2004; جلد 141، ص 477–491. [ Google Scholar ]
تروخیلو، جی. لوجان-مورا، س. آهنگ، I.-Y. استفاده از UML و XML برای طراحی و تبادل اطلاعات برای انبارهای داده و برنامه های کاربردی OLAP. J. پایگاه داده Manag. 2004 ، 15 ، 41-72. [ Google Scholar ] [ CrossRef ]
بولیل، ک. بیمونته، اس. Pinet، F. مدل مفهومی برای مکعب های داده های فضایی: نمایه UML و اجرای خودکار آن. محاسبه کنید. ایستادن. رابط ها 2015 ، 38 ، 113-132. [ Google Scholar ] [ CrossRef ]
بابر، م. خطک، ع. عارف، ف. Tariq, M. چارچوبی بهبودیافته برای مدل‌سازی سیستم‌های انبار داده با استفاده از نمایه UML. IAJIT 2020 ، 17 ، 562-571. [ Google Scholar ] [ CrossRef ]
راوات، اف. Song, J. یک رویکرد یکپارچه برای تجزیه و تحلیل داده های چند منبعی. فاندم به اطلاع رساندن. 2018 ، 162 ، 311-359. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
ارایسی، ا. Belangour، A. فرا-مدل سازی لایه تجسم داده های بزرگ با استفاده از پردازش تحلیلی آنلاین (OLAP). IJATCSE 2019 ، 8 ، 990–998. [ Google Scholar ] [ CrossRef ]
بولیل، ک. بیمونته، اس. Pinet، F. Un modèle UML et des contraintes OCL pour les entrepôts de données spatiales. De la représentation conceptuelle à l’Implémentation. Ingénierie des Systèmes d’Information 2011 ، 16 ، 11-39. [ Google Scholar ] [ CrossRef ]
پدرسن، تی. جنسن، سی. Dyreson, C. پایه ای برای گرفتن و پرس و جو داده های پیچیده چند بعدی. Inf. سیستم 2001 ، 26 ، 383-423. [ Google Scholar ] [ CrossRef ]
گرانی، گ. Eren, C. مقایسه رویکردهای مختلف انبارهای داده زمانی. آنلاین J. Sci. تکنولوژی 2017 ، 7 ، 17-27. [ Google Scholar ]
ادر، جی. کونسیلیا، سی. مورزی، تی. متامدل COMET برای انبارهای داده زمانی. در مجموعه مقالات چهاردهمین کنفرانس بین المللی مهندسی سیستم های اطلاعاتی پیشرفته، برلین، هایدلبرگ، 27-31 مه 2002. صص 83-99. [ Google Scholar ]
گلفرلی، م. مایو، دی. Rizzi, S. مدل واقعیت ابعادی: یک مدل مفهومی برای انبارهای داده. بین المللی جی. کوپ. Inf. سیستم 1998 ، 7 ، 215-247. [ Google Scholar ] [ CrossRef ]
راوات، اف. تسته، او. تورنیه، آر. Zurfluh، G. زبان های جبری و گرافیکی برای دستکاری های OLAP. بین المللی J. Data Wareh. حداقل 2008 ، 4 ، 17-46. [ Google Scholar ] [ CrossRef ]
آبلو، ا. ساموس، جی. سولر، طرح‌واره‌های مفهومی چند ستاره FES برای سیستم‌های OLAP . UPC Universitat Politècnica de Catalunya BarcelonaTech: بارسلونا، اسپانیا، 2001. [ Google Scholar ]
آبلو، ا. ساموس، جی. Saltor، F. اجرای عملیات برای هدایت طرحواره های ستاره ای معنایی. در مجموعه مقالات ششمین کارگاه بین المللی ACM در مورد ذخیره سازی داده و OLAP—DOLAP ’03، نیواورلئان، لس آنجلس، ایالات متحده آمریکا، 7 نوامبر 2003. پ. 56. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
گروه مدیریت شی (OMG). مشخصات متامدل انبار مشترک (CWM) v 1.1′. 2003. در دسترس آنلاین: https://www.omg.org/spec/CWM/1.1/PDF (در 11 ژانویه 2021 قابل دسترسی است).
مدینه، ا. Trujillo, J. استانداردی برای نمایش خواص چند بعدی: متامدل انبار مشترک (CWM). در پیشرفت در پایگاه های داده و سیستم های اطلاعاتی ; Manolopoulos, Y., Návrat, P., Eds.; Springer: برلین/هایدلبرگ، آلمان، 2002; جلد 2435، ص 232–247. [ Google Scholar ]
کوزوکریا، آ. Fidalgo, R. SDWM: یک متامدل انبار داده فضایی پیشرفته. CEUR Workshop Proc. 2012 ، 855 ، 32-39. [ Google Scholar ]
لتراش، ک. ال گدا، او. رمدانی، م. ایجاد خودکار مکعب OLAP با استفاده از رویکرد MDA. نرم افزار تمرین کنید. کارشناس 2017 ، 47 ، 1887-1903. [ Google Scholar ] [ CrossRef ]
پروژه VISES. 2020. در دسترس آنلاین: https://www.projetvisesproject.eu/ (در 23 نوامبر 2020 قابل دسترسی است).
کرس HDF. 2020. در دسترس آنلاین: https://www.cresshdf.org/ (در 23 نوامبر 2020 قابل دسترسی است).
کنسرت ها 2020. در دسترس آنلاین: https://concertes.be/ (در 23 نوامبر 2020 قابل دسترسی است).
طراحی و نمایش بعد زمان در انبارهای داده سازمانی – یک رویکرد عملی مرتبط با تجارت در مجموعه مقالات چهارمین کارگاه بین المللی در مورد شناسایی الگو در سیستم های اطلاعاتی، پورتو، پرتغال، 13-14 آوریل 2004. صص 416-424. [ CrossRef ][ نسخه سبز ]
مان، اس. Phogat, AK ساخت دینامیک شبکه مکعبی در انبار داده. J. Stat. مدیریت سیستم 2020 ، 23 ، 971-982. [ Google Scholar ] [ CrossRef ]
پدرسن، تی. Jensen, CS مدل سازی داده های چند بعدی برای داده های پیچیده. در مجموعه مقالات پانزدهمین کنفرانس بین المللی مهندسی داده، سیدنی، استرالیا، 23 تا 16 مارس 1999. صص 336-345. [ Google Scholar ]
Racines—L’Economie Sociale et Solidaire en Belgique et en Region Hauts-de-France. 2020. در دسترس آنلاین: https://racines.projetvisesproject.eu/ (در 28 نوامبر 2020 قابل دسترسی است).
Nys, G.-A.; کاسپرژیک، جی.-پی. هالوت، پی. Billen, R. یک سیستم بازیابی معنایی در سیستم عامل های وب سنجش از دور. ISPRS Int. قوس. فتوگرام حسگر از راه دور اسپات. Inf. علمی 2019 ، 1593-1599. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
تاردیو، آر. ماته، آ. Trujillo, J. یک معیار جدید داده های بزرگ برای طراحی مکعب OLAP با استفاده از تکنیک های پیش تجمع داده ها. Appl. علمی 2020 ، 10 ، 8674. [ Google Scholar ] [ CrossRef ]