امروزه بیشتر شرکتها در صنایع مختلف از مول Relational یا (RDBMS) برای ذخیره کردن و مدیریت اطلاعات مهم کاری و شغلی استفاده می کنند. در حقیقت سه عرضه کننده مهم Data Base بزرگترین شرکتهای نرم افزاری در کل دنیا هستند، oracle، CBM (DB2)، Microsoft (S21 Server) در طول 4 سال گذشته XML به طور غیر قابل بحثی هم برای تبادل داده ها و هم برای مدیریت contentها به صورت استاندارد درآمده است. بنابراین بسیاری از توسعه‌دهندگانData Base و Applicationها با این مساله روبرو شده اند که داده های XML را به شکل relational تبدیل کنند.

بعد از اینکه دلایل imput کردن (اکیومنتهای XML به Relational Data Base را مطرح کردیم، با استفاده از مثالهای ساده به صورت مفهومی شرح خواهیم داد که چگونه هر XML Document را به Relational Data Base map کنیم، در بخش آخر که به توسعه دهندگان Java اختصاص می یابد شرح خواهیم داد که چگونه XML را به طول رابطه ای Data Base مپ کنیم، JDBC و SAXAPI برای هر برنامه‌نویس یک راه جهانی برای mport کردن داکیومنتهای XML به مدل رابطه‌ای پایگاه داده فراهم
می کنند.

I. مبانی XML/ RDB

چرا Data Base های رابطه ای و XML تکمیل کننده یکدیگر هستند به جای اینکه در رقابت با یکدیگر باشند؟ XML تاثیر بسیار وسیعی روی تکنولوژی صنعت داشته است تا آنجا که بسیاری فکر می کنند Data Base های XML سرانجام جایگزین بیشتر RDBMS های رایج خواهد شد. حالا که حرفه ای های IT شروع به پیاده سازی راه حلهای قابل دوام برای XML کرده اند در این زمینه هیجان و برانگیختگی برای تلاش به وجود آمده است.

با توجه به این تکنولوژی جدید به این نتیجه می رسیم که XML و RDBMS می‌توانند به عنوان تکنولوژیهای تکمیل کننده هم مطرح شوند در واقع بهایی که برای استفاده هوشمندانه از این دو تکنولوژی پرداخته می شود قابل توجه است برای اینکه توانایی های منحصر به فرد این دو دارای جنبه های بسیار متنوعی است.

Relational Data Base ها بلند آوازه هستند به خاطر قابلیت جستجو، استفاده از SQL و برای پرس و جوی موثر و کارایی چون از indexها استفاده می کند آنها Data را به طور کار آمدی ذخیره می کنند بدون هیچ افزدنگی. چون هر واحد از اطلاعات در یک مکان ذخیره شده است (نرمال سازی).

قابلیت اطمینان آنها و قابلیت سنجش آنها برابر است و می توانند در دسترس باشند برای تعداد زیادی از کاربردهای همروند به علاوه با استفاده از مکانیزم های loclcing و caching دارای مدیریت قوی و جنبه های امنیتی بالایی هستند.

هرچند با وجود ابتکارات اخیر در زمینه XML و تکامل استانداردهای پدید آمده جدید مثل xquerg هنوز هم XML از رقابت با تکنولوژی کامل و چندین ساله‌ای مانند RDBMS به عنوان یک قالب برای Data Base دور است.

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

1- Text Base است. 2- قابل خواندن توسط انسان است. 3- مستقل از Platform است و 4- Open Standard است در واقع برای همه Systemها کم کم به صورت Lingua France در می آید.

ماهیت خود تشریح کننده آن باعث می شود که داده های ساخت یافته را بدون هیچ اطلاعات اضافی تشریح کند.

ساختار آن اصلی است. و برای یک سند XML باعث صحت و درستی انتقال و ارائه بیشتر آن می شود. اینکه بیشتر از هر استاندارد دیگری قابلیت درک شدن مستقیم را دارد از پیش معلوم است که در آینده به دلیل قابلیت اطمینان، قابل سنجش بودن و کارایی بالایی Save شدن Dataها در مول Relational حالا دیگر ضروری است که بتوانیم XML را به Relational Data Base، map کنیم.

2- چرا مستندات XML را به Relational Data Base، import کنیم؟

a- تبادل داده ها

حرفه ها در سراسر صنایع بر این تلاش هستند که XML را سازگار کنند با اینکه Data را بین Application ها (A2A) و سازمانها (B2B) به اشتراک بگذارد XML یک راه بدیهی است برای سیستمهای ناهمگن (Heterogenous) که داده ها را در شبکه به اشتراک بگذارند. به علاوه به عنوان روش استانداردی برای ارسال و دریافت داده ها توسط شرکتهای نرم افزاری پذیرفته می شود. در واقع پیام رسانی XML به صورت تصاعدی جایگزین قالب اختصاصی EDI می شود به منظور انجام معاملات Bussiness to Bussiness ماهیت خود تشریحی XML باعث تبادل آسان تراکنشی اطلاعات بین شرکای حرفه ای سیستمهای ناسازگار می شود، بنابراین به طور کلی ارتباطات B2B را آسان می کند و آن را جایگزین EDI می کند.

b- XML Data Repositorg

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

بزرگترین رقیبان در زمینه XML Data Base، Oracle، S2L Server هستند.

متاسفانه اینترفیس RDMS XML از یک فروشنده به فروشنده دیگر متفاوت است و قابل حمل نیست.

به عنوان باقیمانده این مقاله سعی دارد ثابت کند که تفاوت ماهیتی بین شکل ذخیره‌سازی داده در این دو فرم باعث می شود map کردن یکی به دیگری بسیار سخت شود و import کردن سندهای XML به Relational Data Base لازم است.

هرچند که این یک پروسه بحرانی است که تجارت انتخاب کرده است.

c- امکان پیشرفت Relational Data توسط سرویسهای وب

سرویسهای وب همان علاقه اولیه ای ار که Java، S سال پیش XML دو سال پیش در صنعت کامپیوتر داشت را تجربه می کنند.

و توسط تمام غولهای نرم افزار مثل Inicrosoft، NET و FBM و Sun و Oracle و HP و… پشتیبانی می شود. یک سرویس وب یک Application Interface وابسته به برنامه را توسط Remote Application ها قابل دستیابی می کند همانطور که یک HTML Server یک واسط کاربر را برای Bruser قابل دستیابی می کند.

سرویسهای وب با استفاده از یک پروتکل مبنی بر XML به نام Simple Abject Access Protocol (SOAP) قابل دستیابی می شوند.

همچنین Data به عنوان نوع XML باز گردانده می شود. بنابراین با استفاده از سرویسهای وب داده های XML می توانند به صورت Transparent با Data Base، import شوند.

توسعه دهندگانی که قصد دارند که از پایگاه داده Relation شان به عنوان یک سرویس وب استفاده کنند، قانونهای Mapping این مقاله را بسیار آموزنده یافته اند.

3- مدل Relational در مقابل نمایش سلسله مراتبی Data:

هنگامی که به map کردن XML به یک Relational Data Base نگاه می کنیم با دو ساختار داده ای کاملاً متفاوت مواجه می شویم.

a- ساختار داده ای Relational:

یک پایگاه داده Relational به بهترین نحو به عنوان یک اسکمای Data Base توصیف شده است و توسط موجودیتهای گوناگون (جداول) که ساخته شده برای پاسخگویی به نیازهای کاربران تعریف شده است Relational Data Base توسط مجموعه ای از جداول که توسط روابط یک به یک، یک به چند و چند به چند به هم پیوند داده می شوند نشان داده می شود هر جدول از مجموعه ثابتی از ستونهای ثابت (که فیلدهم نامیده می شوند) ساخته می شوند که همان Attoibute ها در
Data Model هستند.

همچنین تعداد نامحدودی از سطرها (یا رکوردها) که در هر جدول وجود دارند. یک پایگاه داده رابطه‌ی از سیارها از Data Type ها پشتیبانی می کند هر جدول با یک کلید منحصر به فرد (Primary Key) مشخص می شود که بقیه جداول می توانند از طریق کلید خارجی خودشان به این کلید اصلی ارجاع داشته باشند طراحی جداول Relational، Data Base را جواب تمام نیازهای موجود می کند وتوسط نرمال سازی تمام Dataها با جزئیات قابل استفاده اند چون هر بخش غیر کلیدی داده تنها در یک مکان حق قرار گرفتن دارد. (نرمال سازی)

b- ساختار داده ای XML

در مقایسه، بهترین راه نمایش داده متعلق به XML، ساختار درخت است و روابط بین عناصر نیز توسط Containment بیان می شود. هر نود درخت توسط یک عضو متعلق به XML مشخص می شود که می تواند یک یا چند Attribute را در خود نگاه دارد درجه پیچیدگی این درخت توسط یک DTD مشخص می شود (Document Type Definition) یا یک اسکمای XML.

توانایی XML بعضی وقتها نقطه ضعف آن است چون می تواند یک قالب همه منظوره داشته باشد و یک ساختاری پایه که هر عنصر داده ای را تقریباً همه جا نشان دهد، در مقابل می تواند به عنوان یک ساختار سلسله مراتبی محکم در Application های دیگر مطرح شود که همه اینها بستگی به DTD یا اسکمای XML ای دارد که آن را مشخص می کند. اگرچه ذاتاً نمایش دادن داده های رابطه ای برای XML سخت است چون به سختی می تواند مجموعه ای از روابط موجود بین جداول رابطه ای در یک سند XML را نمایش دهند Constraint هایی که در RDBMS وجود دارند و باعث می شوند که بسیار کارا باشد در XML وجود ندارند به علاوه قالب بندی شل XML به کلی با استراتژیهای کارای XML ضدیت دارد بنابراین مپ کردن یک سند XML به یک پایگاه داده رابطه ای در بیشتر حالتها پیچیده است همچنین نیاز به یکسری تخصصها و مهارتها هم برای RDMS و هم طراحی داده های XML هست و همینطور یک متد برای مپ کردن هر عنصر از اسکمای XML به اسکمای
Data Base.

4- XML Schemas VS.DTDS

برای رسیدن به مقصودمان باید راهی بیابیم برای تعریف دقیق ساختار درختی XML قبل از شروع به map کردن آن، بخشی از توانایی XML از انعطاف پذیری آن در ساختن عناصر و Attribnte ها ناشی می شود بنابراین برای تعریف و معتبر کردن ساختار XML به فایل دیگری نیاز داریم در ابتدا به این خاطر که XML از نسخه قدیمی تری به نام SGML پدید آمده تنها توسط DTD ها تعریف می شود.

امروزه، با وجود اینکه اکثر سندهای XML توسط DTDها تعریف می شوند، اسکماهای XML که توسط W3C تعریف شده اند- به جای DTDها جایگزین می‌شوند تا بر محدودیتهایی که ماهیتاً در DTDها وجود داشت غلبه کنند به این دلیل مایکروسافت برای خودش فرمت و شکلی از اسکمای XML تعریف کرده XDR (XML Data Reduced).

ممکن است ظرف 3-2 سال آینده اسکمای XML راهی جهانی شود برای نشان دادن ساختار اطلاعات مربوط به XML در مقایسه با DTDها که از Syntax متفاوتی استفاده می کنند اسکماهای XML تنها یک Document دیگر از XML است در نتیجه قابل توسعه است. به علاوه آنها از مجموعه ارزشمندی از انواع داده و محدودیتهای عناصر که خیلی مهمند پشتیبانی می کنند همچنین می توانیم تعداد عناصر تکرار شده را هنگامی که داده تعریف می شود نگاه داریم که این کار در DTDها ممکن نبود.

به این خاطر که اسکماهای XML، همان داکیومنتهای XML هستند به راحتی می‌توانند توسط Style Sheet های XML نمایش داده شوند برای نشان دادن سازگاری سریع این استاندارد جدید بعضی از XMLها با گروهها کار می کنند مانند Legal XML که در نظر دارد حرکتی به سمت XML Schema داشته باشد. در بقیه این مقاله ها از XML Schema به جای DTD استفاده می کنیم به خاطر مزایایی که در بالا یادآور شدیم و همینطور برای آشنا کردن خوانندگان با استاندارد جدید.

در بخش 2 از کلمات کلیدی Chice و Sequence استفاده خواهیم کرد که توسط اسکمای XML W3C تعریف شده است.

II. Unmarshaling به وسیله مثالها:

XML Schema پیش از 44 نوع داده (Data Type) درون خود دارد در مقایسه با DTD که تعداد کمی Data Type دارد، به عنوان پیامد انواع داده XML Schema می‌توانند به درستی به نوع داده های مدل Relational Data Base، map شوند.

1- mapping مبنی بر Table و جدول

قبل از Unmarshaling سندهای پیچیده XML به مدل Relational Data Base، با آسانترین تغییر شکل به یک Relational Data Base شروع می کنیم: Mapping مبتی بر جدول

در زیر سند XML را Unmarshall می کنیم که دو سری از کارمندان را در یک سازمان لیست می کند.

همانطور که طراحی شده این داده می تواند به آسانی در یک جدول Relationa مانند زیر Insert شود.

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

هنگامی که به Relatioonal Data Base، map می کنیم، Attributeهای XML می‌توانند به ستونها مپ شوند دقیقاً با همان روشی که عناصر XML می توانند مپ شوند هر دوی آنها یک نوع از رابطه را برای RDBMS نمایش می دهند: (Containment) بنابراین داده متعلق به XML می توانند به همین شکل map شود.

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

این اسکمای XML حداقل سندهای XML را نشان می دهد با تنها یک نوع ترکیبی و با لیستی از Attribute های تکراری.

2- Exressing Containment

اکثر سندهای XML ساختار پیچیده تر و سطوح Containment سخت تری از مثال بالا دارند فرض می کنیم که سند XML شامل آدرس خانه هر کارمند است.

طابق با خصوصایت W3C، یک نوع پیچیده دارای یک یا چند عنصر است، مندرجات ترکیبی و بعضی از Attributeها جایی که یک نوع ساده مقدار داده ای منفردی را نگاه می دارد. برای هر عنصر با نوع ساده، نیازمند این هستیم که جدول جدیدی بسازیم که داده مطابق با آن را نگاه دارد که در این مثال اطلاعات مربوط به آدرس خانه کارمند است. به عنوان یک قانون عمومی یک نوع Complex توسط کلید اصلی به جدول map می شود و یک نوع Single (ساده) به یک ستون map می‌شود، در اغلب موارد ما مطمئن نیستیم که مقدار یک عنصر خاص XML، منحصر به فرد باشد پس باید هنگام map کردن یک کلید اصلی ایجاد کنیم.

بنابراین همزمان مجبوریم که یک کلید اصلی ایجاد کنیم که مقدارش خارج از جداول Relational بی معنی است تا بتوانیم قانون جامعیت بازگشتی را حفظ کنیم. هنگام Import کردن داکیومنتهای Complex، XML تعداد بسیاری از کلیدها ممکن است ساخته شوند و Join های بسیاری ممکن است صورت بگیرد اگر تعداد Join بین جداول زیاد شود، باعث کاهش کارایی می شود و همینطور باعث می شود که اسکمای Data Base بسیار پیچیده شود و از حالت قابل نگهداری بیرون بیاید.

توجه: برای اینکه بتوانیم Primary Key را به صورت خودکار در یک
Relational Data Base ایجاد کنیم می توانیم از نوع داده Identity استفاده کنیم که توسط اکثر پایگاههای داده رابطه ای پشتیبانی می شود.

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