مدیریت داده های مکانی : مدل های داده های مفهومی:در مرحله اولیه طراحی پایگاه داده، یک مدل داده مفهومی به عنوان مشخصات مستقل از فناوری دادهها برای ذخیره در یک پایگاه داده ایجاد میشود. این مشخصات اغلب به شکل یک نمودار رسمی به خود می گیرد. فرآیند مدلسازی دادههای مفهومی به منظور تقویت درک مشترک بین مدلسازان داده و ذینفعان هنگام ایجاد مشخصات است. به این ترتیب، یک مدل داده مفهومی باید توسط افرادی با تخصص کم یا بدون تخصص فنی-رایانه ای به راحتی قابل خواندن باشد زیرا دید جامع از اطلاعات مهمتر از نمای دقیق است. در یک مدل داده مفهومی، کلاسهای موجودیت دستههایی از چیزها (شخص، مکان، چیز و غیره) هستند که دارای ویژگیهایی برای توصیف ویژگیهای چیزها هستند. روابط می تواند بین کلاس های موجودیت وجود داشته باشد. نمودارهای موجودیت-رابطه راهی محبوب برای توصیف کلاسها، ویژگیها و روابط موجودیت بوده و هستند. نمادهای مختلفی برای نمودارها در طول سال ها استفاده شده است. هدف اصلی در مورد یک مدل داده مفهومی و نمودار موجودیت-رابطه متناظر با آن این است که آنها باید محتوا و معنای داده ها را در زمینه های اطلاعاتی ذینفعان برجسته کنند، در حالی که مشخصات ساختار منطقی را به فاز دوم طراحی پایگاه داده به نام مدل سازی داده های منطقی موکول کنند.
Fatal error: Uncaught TypeError: ltrim(): Argument #1 ($string) must be of type string, WP_Error given in /home/gisland1/public_html/wp-includes/formatting.php:4482 Stack trace: #0 /home/gisland1/public_html/wp-includes/formatting.php(4482): ltrim(Object(WP_Error)) #1 /home/gisland1/public_html/wp-content/themes/xtra/functions.php(3349): esc_url(Object(WP_Error)) #2 /home/gisland1/public_html/wp-content/themes/xtra/single.php(19): Codevz_Core_Theme::generate_page('single') #3 /home/gisland1/public_html/wp-includes/template-loader.php(106): include('/home/gisland1/...') #4 /home/gisland1/public_html/wp-blog-header.php(19): require_once('/home/gisland1/...') #5 /home/gisland1/public_html/index.php(17): require('/home/gisland1/...') #6 {main} thrown in /home/gisland1/public_html/wp-includes/formatting.php on line 4482
1. تعاریف
مدل داده : تعاریف زیادی از مدل داده وجود دارد، اما دو دیدگاه اصلی وجود دارد. جامع ترین تعریف مدل داده از ادگار کاد (1980) می آید: یک مدل داده از سه جزء تشکیل شده است: 1) ساختارهای داده، 2) عملیات روی ساختارهای داده، و 3) محدودیت های یکپارچگی برای عملیات و ساختارها. دیدگاه دوم از جیمز مارتین (1976) و دیگرانی که ایده نمودارهای ساختار داده (پایه) را توسعه دادند، ناشی می شود. به این ترتیب، با اولین مؤلفه بیان شده توسط Codd (1980) مطابقت دارد و در این سادگی، نسخه محبوب تر است. ما در اینجا از نسخه محبوب تر استفاده می کنیم. با این حال، مؤلفه های دوم و سوم Codd (1980) برای درک کامل چگونگی تبدیل داده ها و مشتقات داده ها به اطلاعات ضروری هستند.
مدل دادههای مفهومی : یک ویژگی مستقل از فناوری دادههایی که در یک پایگاه داده نگهداری میشوند. کانون ارتباط بین ذینفعان کسب و کار و مدل ساز داده است. (Simsion & Witt, 2005, p. 17)
2. مدل های داده، مدل سازی داده ها، و مدل سازی داده های مفهومی
از دیدگاه مدیریت داده، دو دیدگاه از یک مدل داده مشترک است. یک نما فقط بر یک ساختار داده متمرکز است، در حالی که نمای دوم شامل یک ساختار داده به اضافه عملگرها و قوانین است. اولین دیدگاه همانطور که توسط West (2011، p.5) ارائه شده است، یک مدل داده را به عنوان “… ساختار و معنای مورد نظر داده” تعریف می کند. دیدگاه کاملتر ارائه شده توسط Codd (1980، ص 112) مدل داده را به عنوان سه جزء تعریف می کند: 1) مجموعه ای از انواع ساختار داده (همانطور که توسط West 2011 توضیح داده شده است). اما همچنین، 2) مجموعه ای از عملگرها یا قوانین استنباط، که می تواند برای هر نمونه معتبر از انواع داده های فهرست شده در (1)، برای بازیابی یا استخراج داده ها از هر بخش از آن ساختارها در هر ترکیب مورد نظر اعمال شود. 3) مجموعه ای از قوانین یکپارچگی عمومی، که به طور ضمنی یا صریح مجموعه ای از حالت های پایگاه داده سازگار یا تغییرات حالت یا هر دو را تعریف می کنند — این قوانین گاهی اوقات ممکن است به عنوان قوانین درج-به روز رسانی-حذف بیان شوند. در توصیف مدل داده ارائه شده در اینجا، ما مشارکت در درک عمومی توسط وست (2011) را محدود می کنیم و تشخیص می دهیم که دیدگاه Codd (1980) به ویژه برای طراحی نرم افزار مدیریت پایگاه داده در مقابل محتوای و ساختار داده در طراحی پایگاه داده مفید است. .
در زمینه مدیریت داده، مدلسازی داده یک فرآیند گردش کار برای انجام طراحی پایگاه داده است که از تجزیه و تحلیل معنایی یک دامنه کاربردی ناشی میشود. که در آن سه سطح انتزاع مدل داده به نام های مفهومی، منطقی و فیزیکی فرآیند کامل طراحی پایگاه داده را تشکیل می دهند (Simsion & Witt, 2005). مشارکت در اینجا فاز مدل داده مفهومی طراحی پایگاه داده را توصیف می کند، در حالی که فازهای مدل داده های منطقی و فیزیکی در ورودی های جداگانه برای مجموعه دانش GIS&T توضیح داده شده است. یک مدل داده مفهومی … “یک (نرم افزار) مشخصات مستقل از فناوری داده ها است که در یک پایگاه داده نگهداری می شود” (Simsion & Witt, 2005, p. 17). یک مدل داده مفهومی حاوی محتوای داده برجسته از جمله روابط در مورد یک دامنه موضوع محور برای تقویت درک مشترک بین توسعه دهندگان پایگاه داده و سهامداران برای یک برنامه سیستم اطلاعاتی است. اغلب از نظر محتوا ساده است، اما در هدفش پیچیده است، زیرا ممکن است دارای روابط بسیار به چند برای یک موضوع باشد. یک مدل داده مفهومی باید توسط افرادی با تخصص کم یا بدون تخصص فنی-رایانه ای به راحتی قابل خواندن باشد زیرا دیدگاه برجسته از اطلاعات مهمتر از نمای دقیق است. معنی داده توسط هر دو کلاس داده و همچنین با روابط بین / بین کلاس ها منتقل می شود. یک مدل داده مفهومی به یک مدل داده منطقی ترجمه می شود که بر ساختار منطقی تأکید دارد، که سپس به یک مدل داده فیزیکی ترجمه میشود که بر ساختارهای ذخیرهسازی در نرمافزار مدیریت داده خاص تأکید دارد (به مشارکتهای GIS&T BOK برای مدل دادههای منطقی و مدل دادههای فیزیکی مراجعه کنید). شکل یک عبارت برای یک مدل داده مفهومی می تواند یک روایت یا نمودار باشد، اما معمولاً یک نمودار و در بهترین حالت، یک نمودار قابل خواندن با ماشین است.
3. زبان برای مدل سازی داده های مفهومی
پیتر چن (1976) یکی از اولین کسانی است که به طور رسمی داده ها را در سطح مفهومی برای پیاده سازی در سیستم های پایگاه داده مشخص می کند و به مدل سازی داده های معنایی معروف شده است. او رویکرد خود را مدل نهاد-رابطه نامید. رویکرد پیشگامانه او زمینهای از مدلسازی مفهومی برای هوش مصنوعی، پایگاههای داده و زبانهای برنامهنویسی را تقویت کرد (Brodie, Mylopoulos, & Schmidt, 1984). تا اواخر دهه 1990، رویکرد نهاد-رابطه (ER) همچنان یکی از محبوبترین رویکردهای مدلسازی داده مفهومی برای مهندسی اطلاعات بود. در اواخر دهه 1990، مدل شی-نقش (ORM) به عنوان جایگزینی برای رویکرد نهاد-رابطه ظاهر شد (Halpin، 1998). در ORM یک ویژگی برای یک شی (شیء یا متغیر) به رابطه ای ترجمه می شود که به آن یک نقش برای شیء می گویند و گفته می شود که توسط کاربران راحت تر قابل درک است. علاوه بر این، در اواخر دهه 1990، تکنیکهای شیگرایی و مدلسازی شی در زبان مدلسازی یکپارچه (UML) به عنوان تلاشی برای تعمیم مهندسی سیستمهای نرمافزار ادغام شدند (Rumbaugh, Jacobsen, & Booch, 1999). چندین نوع از نمودارهای مدل داده مفهومی که عموماً «نمودار ساختار» نامیده میشوند، اکنون به عنوان بخشی از تکنیکهای مدلسازی شی وجود دارند. نمودارهای کلاس شی UML برای طراحی پایگاه داده، به ویژه در سطوح منطقی و فیزیکی استفاده شده است (نایبورگ و ماکسیمچوک، 2001). هالپین (2002) مقایسه ای بین رویکردهای ER، ORM و UML برای مدل سازی مفهومی ارائه می دهد. شباهت ها بیشتر از تفاوت هاست اما باید زبانی را برای بیان معنایی یک برنامه انتخاب کرد. هر دو ER و ORM عمدتا برای مدل سازی پایگاه داده استفاده شده اند. UML بیشتر برای مهندسی نرم افزار استفاده شده است. مدلهای داده مفهومی ER ساختارهای سادهای برای نمایش اطلاعات، با قوانین کمی برای تقویت بیان معنادار دارند. ساختارها معمولاً شامل کلاس موجودیت، ویژگی و روابطی هستند که در یک سند طرحواره یادداشت شده اند. در نتیجه، ما رویکرد ER را در اینجا توصیف میکنیم، اما خواننده را تشویق میکنیم تا سایر رویکردهای ارائهشده از طریق نقلقولهای مرجع را بررسی کند. با قوانین کمی برای پرورش بیان معنادار. ساختارها معمولاً شامل کلاس موجودیت، ویژگی و روابطی هستند که در یک سند طرحواره یادداشت شده اند. در نتیجه، ما رویکرد ER را در اینجا توصیف میکنیم، اما خواننده را تشویق میکنیم تا سایر رویکردهای ارائهشده از طریق نقلقولهای مرجع را بررسی کند. با قوانین کمی برای پرورش بیان معنادار. ساختارها معمولاً شامل کلاس موجودیت، ویژگی و روابطی هستند که در یک سند طرحواره یادداشت شده اند. در نتیجه، ما رویکرد ER را در اینجا توصیف میکنیم، اما خواننده را تشویق میکنیم تا سایر رویکردهای ارائهشده از طریق نقلقولهای مرجع را بررسی کند.
3.1 نهاد و کلاس موجودیت
موجودیت یک شخص، مکان یا چیزی از دنیای گذشته، حال، آینده یا خیالی است که می توان با استفاده از یک یا چند ویژگی برای آن اندازه گیری کرد. کلاس موجودیت مجموعه ای از موجودیت ها با ویژگی های مشابه است. یک نوع موجودیت را می توان تعریف کلاس در نظر گرفت. یکی از بزرگترین مشکلات در مدیریت داده ها، شناسایی، نامگذاری و تعریف کلاس های موجودیت است. برای به اشتراک گذاشتن بینش، باید درک خود را در مورد یک موضوع به اشتراک بگذاریم. تبدیل متن به بخشی صریح از داده ها، به عنوان مثال، توصیف تمام داده های مورد نیاز برای زمینه، وضوح داده ها را تقویت می کند. کلاس های موجودیت باید نمایانگر ویژگی های اساسی یک شخص، مکان یا چیز باشد، و نه نقشی که در یک زمینه خاص ایفا می کند. نقش یک ویژگی ثانویه است و نه یک ویژگی اولیه موجودیت (Simsion & Witt, 2005).
3.2 ویژگی های موجودیت
شخصیت زیربنایی یک شخص، مکان یا چیز بر حسب صفات مشخص می شود. ویژگی های اولیه و ثانویه را می توان به عنوان مبنای طبقه بندی و تعریف نوع موجودیت شناسایی کرد (Nyerges, 1991). صفت اولیه صفتی است که باید به عنوان بخشی از نوع کلاس برای مشخص کردن هویت آن گنجانده شود. یک ویژگی ثانویه ویژگی است که لزوماً برای تعیین یک نوع کلاس مورد نیاز نیست. یک نوع موجودیت با ترکیب مجموعهای از ویژگیهای اولیه برای دادن معنای کلاس موجودیت تشکیل میشود. این ویژگیهای همراه با هم هویت نوع موجودیت را تشکیل میدهند. هنگامی که یکی از ویژگی های اصلی حذف می شود، نوع موجودیت بر اساس هویت نوع، به یک کلاس متفاوت تبدیل می شود. به دنبال گنجاندن ویژگی اولیه در بالا، هنگامی که یک ویژگی ثانویه از یک نوع موجودیت حذف می شود، نوع موجودیت همان کلاس باقی می ماند. ویژگیهای نامزد باید بهعنوان نمایانگر روابط با سایر انواع موجودیت در نظر گرفته شوند. هر ویژگی کاندیدای رابطه با موجودیت دیگری است (Simsion & Witt, 2005).
3.3 روابط
یک کلاس موجودیت تعریف شده توسط یک نوع موجودیت می تواند با کلاس موجودیت دیگر یا از طریق یک کلاس رابطه با خودش مرتبط شود. روابطی که در طول زمان ادامه می یابند، روابط پایدار یا ساختاری نامیده می شوند. روابط موقتی می تواند وجود داشته باشد و به آنها روابط زودگذر یا اتفاقی می گویند. روابط پایدار آسان تر از آنهایی که زودگذر هستند طراحی می شوند. روابط اغلب به دلیل نوع و سطح خاصی از ویژگی های واجد شرایط موجودیت ها به وجود می آیند. فعالیتها و انجمنها باید با انواع موجودیتها نشان داده شوند، زیرا روابط بینشی را برای نقشهای درگیر با یک موجودیت فراهم میکنند.
روابط بین موجودات اصلی است. Cardinality به تعداد نمونه های یک کلاس موجودیت مرتبط با نمونه های کلاس موجودیت دیگر اشاره دارد. به طور بالقوه، 0، 1، یا چند نمونه از یک کلاس موجودیت وجود دارد که می تواند با نمونه(های) کلاس موجودیت دیگر مرتبط باشد. برخی از طراحان کاردینالیته را به عنوان یک مسئله مدل داده منطقی به جای یک مسئله مدل داده مفهومی می بینند (West, 2011). اگر کاردینالیته در سطح مفهومی نشان داده نشود، باید در سطح مدل داده های منطقی نمایش داده شود. تفاوت در رویکرد بستگی به این دارد که آیا مجموعهای از موجودیتها برای تفسیر مشکلات برنامه معنادار هستند یا خیر. آنها اغلب برای مشکلات جغرافیایی هستند، بنابراین ارائه آنها در سطح مفهومی ترجیح داده می شود.
4. نمودار مدل داده مفهومی
فرض بر این است که یک طرحواره قابل خواندن با ماشین است و اغلب به شکل یک نمودار برای افزایش خوانایی به خود می گیرد. نمادهای مختلفی در راستای زبانهای مختلف برای فرمولبندی مدلهای داده مفهومی همانطور که قبلاً توضیح داده شد پدید آمدهاند. در زیر ابتدا نمادهای مرتبط با مدل سازی ER را مورد بحث قرار می دهیم و سپس به مثالی در مورد قطعات زمین می پردازیم.
4.1 نشانه گذاری نمودار
نمودارها معمولاً برای افزایش درک موضوعات پیچیده ایجاد می شوند. از آنجایی که پایگاه های داده اغلب حاوی اطلاعات قابل توجهی هستند، نمودارسازی مکمل مهمی برای فرآیند طراحی می شود. نمودار رابطه موجودیت از سه جزء اساسی تشکیل شده است که در بالا ذکر شد، و بنابراین به سه دسته نمادگذاری نیاز دارد، یکی برای هر یک از انواع، ویژگیها و روابط موجودیت (کلاس). نماد استاندارد برای انواع موجودیت معمولاً شامل استفاده از جعبه های مستطیلی با یک برچسب برای نام نوع موجودیت است. گاهی اوقات برچسب خارج از جعبه است، گاهی اوقات داخل جعبه. این واقعاً به فروشنده نرم افزار بستگی دارد، و اینکه آنها چه نمادهایی را اتخاذ کرده اند. سازگاری واقعاً قانونی است که باید استفاده شود، صرف نظر از جایی که برچسب ممکن است ظاهر شود. نماد استاندارد برای ویژگی ها شامل فهرست کردن ویژگی ها در داخل جعبه و همچنین در کنار یک جعبه است. گاهی اوقات علامت گذاری در یک کادر جداگانه در کناره قرار گرفته است، اما کمتر رایج است.
نمادهای مختلفی برای روابط در طول سالها پدیدار شدهاند، بسیاری از تفاوتها مربوط به نحوه بهترین توصیف روابط، و بهویژه اصلی بودن روابط است، زیرا راههای زیادی برای به تصویر کشیدن این اطلاعات وجود دارد. یک مثلث با خطوطی که از هر دو طرف بیرون میآیند و با علامت کاردینالیته مشخص میشود، نماد اصلی مورد استفاده در ER Notation بود (چن 1976). خطوط با نوک پیکان در دو انتهای خط، همراه با یک علامت عددی برای کاردینالیته، در UML استفاده شده است. خطوطی با نمایش پای کلاغی، که در آن یک خط به معنای 1 و سه خط به معنای تعداد زیادی است، با 0 نشان دهنده هیچ کدام استفاده نشده است. سیمشیون و ویت (2005، ص 83) رابطه مشابهی را نشان میدهند که با استفاده از شش ابزار نرمافزاری مختلف، که هر کدام نمادهای کمی متفاوت دارند، به تصویر کشیده شده است. هیچ استاندارد واحدی وجود ندارد که “بهترین” در نظر گرفته شود،
4.2 نمونه ای از مدل داده مفهومی موجودیت، ویژگی و نمودار رابطه
در زیر یک نمودار ER اصلاح شده است که یک کلاس موجودیت دارایی و یک کلاس موجودیت ساختمان را نشان می دهد (شکل 1). یک ملک دارای ویژگی هایی است: شناسه بسته، شناسه قطعه و مالک. یک کلاس موجودیت ساختمان دارای ویژگیهایی است: ردپای و تعداد طبقات. رابطه ای بین آنها وجود دارد که “حاوی” است. یک ملک شامل یک ساختمان و یک ساختمان توسط یک ملک است. کاردینالیته خوانده می شود، هر ملک ممکن است 0، 1 یا تعداد بیشتری ساختمان در محدوده خود داشته باشد. نمایش پای کلاغی برای تعیین کاردینالیته 0 یا 1 به چند استفاده می شود.
شکل 1. نمودار موجودیت-رابطه
5. از مدلهای دادههای موردی و مفهومی استفاده کنید
مورد استفاده مجموعه ای از مراحل را به عنوان بخشی از مدل سازی فرآیند کسب و کار هنگام بررسی یک کار کاربردی مشخص می کند. یک مورد استفاده از انجام مدلسازی فرآیند کسبوکار برای شناسایی شرایط قبل از توالی مراحل (پیششرایط)، خود مراحل و شرایط پس از توالی مراحل (شرایط پسا) حاصل میشود. دو سطح از موارد استفاده را می توان بیان کرد، مورد استفاده تجاری و مورد استفاده سیستم. موارد استفاده تجاری بر عملکرد وظایف سیستم اطلاعاتی تمرکز می کنند، در حالی که موارد استفاده از سیستم بر اجرای کار متمرکز هستند. از آنجایی که یک مدل داده مفهومی نمایانگر سطح بالایی از نیازهای اطلاعاتی است، مورد استفاده تجاری برای توسعه کلاسهای داده برای مدلهای داده مفهومی کاربرد بیشتری دارد. در یک مورد استفاده تجاری، توالی فعالیت منجر به درک انواع داده های مورد نیاز می شود. کلاس های داده را می توان از اسم های موجود در توضیحات کار مشتق کرد. با این حال، در یک مورد استفاده از سیستم، یک مدل داده مفهومی میتواند به عنوان بخشی از پیششرطهای وظایفی که باید انجام شود، استفاده میشود. یعنی یک مدل داده مفهومی قبل از اجرای کار وجود دارد و یک چارچوب داده ای است که می تواند برای اجرای کار برای بیان بیشتر کلاس های داده و روابط مورد نیاز بین آنها استفاده شود.
6. از مدل های داده های مفهومی برنامه محور تا سازمانی
بحث فوق بر روی یک کاربرد واحد در یک سیستم اطلاعاتی متمرکز بود. با این حال، سازمانها اغلب برنامههای کاربردی زیادی را انجام میدهند، با احتمال زیادی که بسیاری از برنامهها نیازهای داده را به اشتراک میگذارند. در نتیجه، جمعآوری مدلهای داده مفهومی برنامهمحور و ترکیب آنها برای ایجاد یک مدل داده مفهومی در سطح سازمانی سودمند است. هدف اصلی از ایجاد یک مدل داده مفهومی سازمانی این است که درک مشترک بین برنامهها را تقویت میکند، در حالی که ناسازگاری در دادهها و اطلاعات ارائه شده به کاربران را کاهش میدهد.
از نتایج، یک طرح واره یکپارچه ایجاد شده است که می تواند برای پشتیبانی از یک انبار داده یا رویکرد پایگاه داده فدرال استفاده شود (Yeung & Hall، 2007). هر دو محیط انبار داده و پایگاه داده فدرال دسترسی مشترک به داده ها را تقویت می کنند و بنابراین هر دو یک محیط پایگاه داده چند کاربره هستند. با این حال، ماموریت های پایگاه داده آنها متفاوت است. یک انبار داده معمولاً دادهها را برای برنامههای پشتیبانی تصمیم ذخیره میکند که در آن طرح دادهها به طور اساسی تغییر نمیکند، اما دادهها در طول زمان تغییر میکنند. پایگاه داده فدرال مجموعه ای از طرحواره ها است که با هدف به اشتراک گذاری داده ها در میان طرحواره هایی که معمولاً عملیاتی تر هستند، ایجاد شده است، به عنوان مثال برای فعالیت های روزانه حیاتی در یک سازمان.
برودی، ام.ال.، میلوپولوس، ج.، و اشمیت، جی دبلیو (1984). در مورد مدل سازی مفهومی . نیویورک، نیویورک: Springer-Verlag.
چن، پی (1976). مدل نهاد-رابطه – به سوی یک دیدگاه یکپارچه از داده ها. معاملات ACM در سیستم های پایگاه داده. نیویورک: انجمن ماشین های محاسباتی. 1 (1): 9-36. DOI: 10.1145/320434.320440
Codd, EF (1970). یک مدل داده رابطهای برای بانکهای داده مشترک بزرگ ارتباطات ACM، 13 (6)، 377-387. DOI: 10.1145/362384.362685
Codd, EF (1980). مدل های داده در مدیریت پایگاه داده ACM SIGMOD Record – مجموعه مقالات کارگاه انتزاع داده ها، پایگاه های داده و مدل سازی مفهومی، 11 (2)، 112-114. DOI: 10.1145/800227.806891
هالپین، تی (1998). مدلسازی نقش شی (ORM/NIAM). در P. Benus, K. Mertins, G. Schmidt, (eds.) Handbook of Architectures of Information Systems , pp. 81-102, Berlin, Spring-Verlag.
هالپین، تی (2002). فرا طرحواره برای مدل های داده ER، ORM و UML: مقایسه، مجله مدیریت پایگاه داده، 13 (2)، 20-30.
نایبورگ، ای جی، و ماکسیمچوک، RA (2001). UML برای طراحی پایگاه داده ریدینگ، MA: ادیسون-وسلی.
Nyerges، T. (1991). چکیده اطلاعات جغرافیایی: وضوح مفهومی برای مدلسازی جغرافیایی. محیط زیست و برنامه ریزی الف ، 23 ، 1483-1499.
رامبا، جی، یاکوبسن، آی، و بوچ، جی (1999). کتابچه راهنمای زبان مدلسازی یکپارچه مرجع . ریدینگ، MA: ادیسون-وسلی.
سیمسون، جی، و ویت، جی (2005). ملزومات مدلسازی داده ، ویرایش سوم. سانفرانسیسکو، کالیفرنیا: Morgan Kaufmann Publishers Inc.
وست، م. (2011). توسعه مدل های داده با کیفیت بالا . سانفرانسیسکو، کالیفرنیا: Morgan Kaufmann Publishers Inc.
Yeung, AKW, & Hall, GB (2007). سیستم های پایگاه داده مکانی . دوردرخت، هلند: Springer.
Codd (1970) مخترع مدل داده های رابطه ای بود، اما علاقه او نسبت به مدل رابطه ای عمومی تر بود، برای ایجاد درک عمیق از اولین اصول مدل سازی داده ها (Codd 1980) که برای درک چگونگی ساخت ضروری است. ، مدیریت و تجزیه و تحلیل پایگاه داده های مکانی- زمانی.
وست، م. (2003). توسعه مدلهای داده با کیفیت بالا، https://www.researchgate.net/publication/242662680_Developing_High_Quality_Data_Models
هاگی، تی (2011). مدل داده مفهومی، https://erwin.com/community/industry-expert-blogs/the-conceptual-data-model