امروزه بیشتر شرکتها در صنایع مختلف از مول 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 اضافه کنیم که با آن به جدول کارمندان ارجاع داشته باشیم.
یا برای پردازش سریعتر می توانیم یک ستون اضافه کنیم که به Home Address در جدول Employe ارجاع داشته باشیم.
3- بعضی از قوانین ساده Mapping a- ترتیب عناصر در یک سند XML با ترتیب ستونها در جدول نشان داده می‌شود و ترتیب عناصر و Attribute در اسکمای XML توسط کلمه کلیدی بیان می شود برای اینکه همان ترتیبی که داده هادر مدل Relational دارند حفظ شود باید مطمئن شویم که سطرها توسط Primarykag (کلید اصلی) مرتب شده اند و همان ترتیب عناصر XML را دنبال می کنند.
اگر چنین نبود باید یک ستون اضافه کنیم که اعداد صحیحی را در خود دارد که این ترتیب را مطابقت می دهد.
b- عناصر دلخواه XML اگر بخواهیم نشان دهیم که یک عنصر XML دلخواه است ستون نظیر آن را Anllable می کنیم برای مثال اگر Ittredate یک Attribute دلخواه باشد (minoccurs=0) ستون مپ شده باید قابلیت Null شدن را داشته باشد.
مدل XML آن به صورت زیر است.
در مثال ما عنصر Jub ممکن است تنها شامل عناصر زیر باشد.
CEO، CTO و CFO و DIRECTOR و MANAEER و GNGINEER و SALESMAN، CONSULTANT و ASSISTANT.
اسکمای XML زیر این روش را نشان می دهد.
در پایگاه داده رابطه ای ما می توانیم یک جدول اضافی ایجاد کنیم که تمام این مقادیر را شامل شود و توسط کلیدهای خارجی و اصلی به آنها ارجاع کنیم.
4- المانهای تکراری (یا تکرار شونده) XML (کاردینالیتی) اکنون متن XMLها، ما را از کامپیوتری که هر یک از کارمندان به کار می گیرند، آگاه می سازد.
اکثر کارمندان تنها یک کامپیوتر دارند، اما مدیر سیستم: جنیفر، سه تا دارد.
اگر تعداد کامپیوترها محدود به سه کامپیوتر شود، ما سه ستون برای نوع کامپیوتر مورد استفاده کارمندان، در جدول کارمندان خواهیم داشت.
کامپیوتر شماره 1، کامپیوتر شماره 2، کامپیوتر شماره 3.
اگرچه اشکال بزرگی در این روش وجود دارد.
برای مثال، اگر حد کامپیوترها برای یک کارمند از سه تجاوز کند، ساختار جدول نیاز به اصلاح خواهد داشت که منجر به مسائل عدیده ای می شود.
رابطه ای یک به چند با استفاده از کلید خارجی به خوبی بیان می شوند.
تعداد المانهای تکراری می تواند بی کران باشد.
این با موارد بسیاری از المانهای تکراری سر و کار خواهد داشت.
اما ما چه اقدامی انجام می دهیم وقتی که المانهای تکراری، المانهای والد متعددی دارند؟
برای مثال، کارمندان ممکن نیست که تنها یکبار از کامپیوترهای همکاران استفاده کرده باشند.
مشاورین حتی ممکن است که هنگام کار روی یک قرارداد طولانی مدت، کامپیوترها را قرض بگیرند، یا ممکن است آزمایشگاه تستی متشکل از کامپیوترهای مورد استفاده کارکنان مختلف برقرار شود.
با توجه به اینکه ما نمی توانیم تعداد نامحدودی کلید خارجی به جدول کامپیوتر خود اضافه کنیم، بنابراین لازم است جدولی برای مرتبط کرد هر کامپیوتر به کاربر یا مکان قرارگیری اش، داشته باشیم.
5- اشاره گرهای ID/IDREF اگر شرکتی معیار سنجشی روی COMPAQ داشته باشد، متن XML اصلی می‌تواند، برای اجتناب از تکرار المانهای یکسان XML از ID و IDREF استفاده کند.
در حقیقت، با توجه به اینکه محتوای اشاره گرها و کلیدها خیلی با پایگاه داده رابطه‌ای مانوس است، بهتر است تا المانهای XML ID را به کلیدهای اصلی متناظر کنیم البته اگر در مورد یکتایی آنها اطمینان داریم.
6- مقدار درهم مقدار درهم در متن های XML سخت، کمیاب است نظر به اینکه توسط صنایع مختلفی، مثل هایی جهت مبادله داده تعریف شده اند.
هرحال استفاده از آن در مدیریت مقادیر و علاوه بر این به طور خاص در صنعت چاپ، بسیار متعارف است.
در حقیقت HTML تقریباً به صورت صریح از مقدار درهم ساخته شده است.
در مثال جاری، به هر کارمندی اجازه داده شده است تا برای معرفی خود تعدادی عبارت به صفحه وب شرکت اضافه کنند.
این معرفی سپس در هر یک از رکوردهای XML کارمندان قرار می گیرد.
آلن مایل است این اطلاعات را در مورد خودش به نمایش گذارد.
به صفحه وب آلن خوش آمدید.
من مدیر برنامه نویس شرکتی هستم که روی تکنولوژی نگاشت XML/RDB متمرکز شده است.
من واقعاً از کار با تیم مهندسی‌مان لذت می برم که گروهی با هوش و آرامند.
در HTML در XML برای کمک به ما در نگاشت این متن به پایگاه داده رابطه ای، بهتر است همه المانهای متنی را با کد اضافی مشخص کنیم.
پس حالا ما داریم: ساده ترین راه نگاشت این فایل XML، بیان دنباله ای از تگ های مختلف با لحاظ کردن ترتیب سطور جدول جدید است.
البته به یک ستون اضافی هم برای تعیین نوع تگ استفاده شده HTML احتیاج داریم.
برای اجتناب از تکرار این المانها ما می توانیم یک جدول Look Up برای هر یک از تگ های HTML استفاده شده، بسازیم.
اگر TAGNAME همیشه مقادیر مختلفی داشته باشد، ما فقط جدول WEBPAGE را خواهیم داشت و TAGNAME جایگزین TAGNO می شود.
7- ارتباط چرخه ای در یک شمای XMLای، برای یک المان ممکن است یک وابستگی بازگشتی داشته باشیم.
برای مثال ما المان را به اضافه می کنیم، و آن المان دوباره می تواند شامل باشد.
برای مثال، جک سرپرست آلن است و لیونل به آلن گزارش می دهد.
در این مورد، ما فقط به یک جدول lookup برای اتصال المانهای مختلف به یکدیگر نیاز داریم.
هنگامیکه یک شمای XMLای یک رابطه چرخه ای را شامل می شود، این به معنی وجود تعداد نامحدودی از المانها در درون یکی دیگر از آنها نیست.
در عمل ما همیشه یک حد مشخصی برای تعداد المانهای تو در تو خواهیم داشت.
در شرکت ما مهندس لیونل می تواند یک کاروند را مدیریت کند، بنابراین به ما در گروهمان چهار سطح می‌دهد، اما این در واقع حد المانهای تو در تو خواهد بود.
8- تمرین: یک مثال پیچیده تر برای ذخیره در پایگاه داده رابطه ای.
برای مرور آنچه که پیشتر بحث کردیم، لطفاً چند دقیقه وقت صرف ایجاد جداول پایگاه داده ای بکنید که قرار است با تمام رابطه های متناظر خود برای نگاشت متن XML زیر به کار رود.
دو شرکت با هم ادغام شده اند ونیاز به امکاناتی برای شرکت دادن یکدیگر در دسترسی به اطلاعات خرید و فروش همدیگر دارند و تصمیم می‌گیرند از XML بهره گیرند.
کمپانی A متن XML زیر را به کمپانی دیگر می‌فرستد و نیاز دارد تا آنرا در پایگاه داده رابطه ای آنان، قرار دهد.
یکبار که تمام کردید به من ایمیل کنید که چه شمای پایگاه داده ای را برای این متن XML پیدا کردید و من نظراتم را برای شما خواهم فرستاد.
1- خلاصه به طور خلاصه، ما هنگام Unmarshaling یک متن XML به یک پایگاه داده رابطه‌ای، می بایست کلیه ساختارهایی را که قبلاً توصیف کرده بودیم، بشناسانیم: انواع ساده و پیچیده، ترتیب، انتخاب، محدوده ها، کار دینالیتی، اشاره گر، مقدار درهم و وابستگی چرخه ای.
پس از آن می بایست آنها را به یک شمای پایگاه داده رابطه‌ای معنی دار متناظر کنیم.
برای شروع یک نمودار برای مدل پایگاه داده درست می کنیم تا کلیه روابط بین جداول را نشان بدهیم.
سپس مطمئن می شویم که تمام المانهای XML و خصوصیات به ستونهای منفرد مرتبط شده اند.
برخی المانها ممکن است نتیجه یک رشته یا عملگرهای عددی باشند آن هم روی یک یا چند مقدار المان XML.
در هنگام انجام این نگاشت لازم است تا مراحل زیر را انجام دهیم: الف- درستی و جامعیت داده را در پایگاه داده رابطه ای حفظ کنیم.
ب- موجودیتهای جداول را معنی دار ایجاد کنیم و به دلایل اجرای بهتر، اتصال را کمینه کنیم.
ج- توجه کنیم که تمام عناصر XML نگاشت داده شوند.
2- استانداردهای کد نویسی RDBMS نظیر اراکل، SQL Server و DB2 شروع به حمایت از عرضه XML کرده است؛ اگرچه هر یک از روشهای اختصاصی و متفاوت خود در این کار استفاده می کنند.
اراکل برای نگاشت به XML با استفاده از ایجاد یک مدل داده شیء رابطه ای از جاوا استفاده می کند.
IBM DB2 از یک فایل تعریف دسترسی به داده کد شده با XML برای تعریف این نگاشت بهره می گیرد و SQL Server، SQL را با معرفی یک سری تابع OPENXML گسترش می دهد.
بنابراین برای برنامه نویسان مهم است تا تنها با یک واسط عمومی سر و کار داشته باشند، مخصوصاً چنانچه سیستم های پایگاه داده متفاوتی در محیط IT وجود داشته باشد.
به همین دلیل ما از یک واسط JDBC برای درخواست داده رابطه ای از SQL استفاده خواهیم کرد.
بعلاوه ما از اهرم API های استاندارد برای دسترسی و دستکاری داده XMLای استفاده خواهیم کرد: DOM و SAX (ضمیمه ب را ملاحظه کنید).
3- قراردادن جداول پایگاه داده رابطه ای در جاوا پیشتر ما فقط متدهایی را توضیح دادیم بدون اینکه کدی بنویسیم.
در بخش بعدی، ما خرده کدهائی را تفسیر و بررسی می کنیم که یک متن XML ای را که شامل اطلاعات کارکنان است با استفاده از SAX می خواند و سپس یک سری MS به جدول EMP را از اطلاعاتی که در همین متن است اجرا می کند.
به منظور ساده سازی، ما تنها به ساده ترین فرم نگاشت: نگاشت براساس جدول اشاره می کنیم.
هدف وارد کردن مثل زیر است: متن XML خود را باز و آنرا با استفاده از SAX (ضمیمه ب) تجزیه می کنیم.
در همین جاست که ما درایور JDBC، پایگاه داده URL، ID کاربر و رمز عبور متناظر با پایگاه داده محیطمان را مشخص می کنیم.
در ضمیمه الف شما لیستی از درایورهای JDBC برای اکثر پایگاه داده های رابطه ای متعارف پیدا خواهید کرد.
4- محدودیتهای این راه برنامه نویس اول اینکه این برنامه کلی نیست و برای هر ساختار XML از انواع مختلف نیاز به برنامه نویس سنتی دارد.
المانهای جدول EMP نظیر empno و job و… hardcoded هستند به این معنا که ما هر زمان که بخواهیم DTD یا شمای XMLای جدید را پیشتیبانی کنیم می بایست که جدیدی را بنویسیم.
ملاحظه گردد که 805 زمان برنامه نویس بجای ایجاد کد جدید صرف نگهداری کد می شود ما به یک راه حل گران توجه می کنیم راه حلی که به سرعت غیرقابل نگهداری خواهد بود.
در مثال قبلی مان خطایاب کاملاً ابتدایی است و می بایست به منظور اهداف رفع اشکال بهینه گردد.
متن XMLای که ما بررسی کردیم برای فهم بهتر آسان شده بود اما پیاده سازی های دنیای واقعی همانطور که در بخش دوم بیان شد بسیار پیچیده تر و حاوی ساختارهای فریبنده‌تری هستند.
ما در مورد نگاشت نوع داده ها نیز از یک مدل XML به یک پایگاه داده رابطه ای صحبت نکردیم همچنین در مورد ایجاد جداول وقتیکه پیش از آن اصلاً وجود نداشته اند یا اینکه چگونه جامعیت داده حفظ می گردد هنگامیکه رکوردهای جدید به پایگاه داده داخل می شوند.
IV.
وارد کردن XML به پایگاه داده رابطه ای با JAllora با وجود اینکه بسته های کدباز برای تغییر شکلهای مقدماتی شبیه آنچه که بیان شد، کافی هستند،برخی از محصولات تجاری می توانند به طور قابل توجهی زمان مربوط به کدنویسی و نگهداری مربوط به واسطهای نگاشت XML-SQL شان را کاهش دهند.
به طور خاص JAllora در نظر دارد تا مساله اجتماع هر کد داده رابطه ای را با متن مدل حل کند بدون اینکه نیازی به دانش گسترده بر روی SQL و… لازم باشد.
ابزارهای آن دو Component عمده نرم افزاری هستند: Allora Mapper و Allora Engine.
همچنین شامل چندین ابزار همروند و ویزاردهائی برای IDE Applications و آداپتورهائی نیز برای Server Applications های مختلف است و همین طور برای ماژولهای اجتماع خدمات وبی.
1- Allora Mapper یک GUI Application است که ایجاد تعاریف نگاشت بین یک مدل W3C یا مثالهای DTD و فیلدهای جدول یک پایگاه داده رابطه ای را حمایت می کند.
این راه برنامه نویس را از نوشتن کدهای پیچیده در اکثر موارد نجات می دهد، متن XML فرمت متفاوتی نسبت به ساختار جدول در RDBMS دارد.
برخلاف فواید بسیار XML-SQL که برای ایجاد نگاشت اختصاصی نیاز به دخالت دست کاربر دارند، و ضعیف پیوند با استفاده از روش بکش و رها کن انجام می شود.
برای کاهش پیچیدگیهای نحوی مدلهای XML و DTD ها، Allora Mapper اینها را در یک روش سه بعدی آسان شده ارائه می دهد.
در همین زمان تعاریف آن تمام اطلاعات مناسب را از فهرست پایگاه داده نشان می‌دهد، نظیر نوع داده، دقت و تعداد رقم اعشاری.
Allora Mapper ایجاد و تغییر پیوندهای بین ویژگیهای عناصر و فیلدهای جدول را پشتیبانی می کند.
همچنین از بازیابی و برپایی قیدهای جامعیتی نیز حمایت می کند.
همه اینها برای اجرای پیوندی کامل در مورد جداول مختلف رابطه ای به کار گرفته می‌شوند.
سایر توابع عمده ای که از ایجاد Predicates حمایت می کنند مثل SQL و عبارات XMLای و پارامترهای دینامیک در تعاریف گزاره ای است.
خصوصیت عمده دیگری که توسط آن حمایت می شود Scripting است.
هنگامیکه طراحان نگاشت زمان طراحی از این روش استفاده می کنند آنها آزادند که از داده SQL ای و یا داده ای XMLای استفاده کنند.
در جاوا یک زبان Script نویس مثل Java Script می تواند هرگونه تغییر شکل پیچیده را به طور صریح ممکن سازد و بنابراین نیازی ندارد که برنامه نویس هر زمان که نیازی به تغییر واسط بود محصول خود را مجدداً کامپایل کند ویا حتی بسازد.
2- Allora Engine این وسیله در جایی است که اجتماع XML اتفاق بیفتد.
یک مجموعه از بسته های Java است که تعاریف نگاشت را از Allora Mapper می گیرند و آنها را برای ایجاد ورودی یا خروجی XML پردازش می کنند.
کلاسهای جاوا مدلهای مختلفی را علی‌رغم تفاوتهای نحوی حمایت می کنند.
با توجه به این مدل API، عملیات XML یا روی مد Batch و یا روی رکورد با رکورد انجام می شوند و هنگام به روز رسانی پایگاه داده، سطوح ایزولاسیون برای حمایت‌های رفتاری ممکن است به کار گرفته شوند.
3- ابزارهای دیگر JAllora ویزاردهائی را برای اجتماع Allora با محیطهای IDE عرضه می کند.
این ویزاردها کدهائی را که براساس تعاریف نگاشتی ارائه می شوند، ایجاد می کنند.
همچنین از انقیاد داده ای Java نیز که دستیابی و اصلاح مقادیر رکوردهای XML را ساده می کنند، حمایت کرده اند.
4- JAllora خلاصه JAllora از نرم افزار Hit با بیش از هشت سال تجربه به عنوان اهرم در طراحی و پیاده سازی میان افزارهای دسترسی داده که شامل ODBC، OLE و… است، استفاده کرده است.
با JAllora، نرم افزار Hit راهی را که می توانست روش استانداردی برای اجتماع XML با پایگاه داده رابطه ای باشد ارائه کرده است.
در حقیقت JAllora با همه عرضه کننده های JDBC که در حال حاضر در دسترسند سازگار است.
برخی از ابزارهای مهم JAllora عبارتند از: توانایی کارکردن با هر مدل XML یا DTD.
یک GUI Mapper قوی که تعریف نگاشت را ساده می کند.
یک راه اعلانی تعریف نگاشت نیست به روش رویه ای پشتیبانی نگاشت.
یک مجموعه از SOAP (پروتکل دسترسی ساده به شی) ها برای سرویسهای وب خود برای ایجاد برنامه های توزیعی.
یک رقیب تکنیکی مهم برای Allora تکنولوژی نگاشت را با پروسسورهای XML شامل Xqvery و XSLT مجتمع خواهد کرد.
با ارائه اجتماع کردنهای کارآمد و یکپارچه، Allora فواید نگاشت متعارف را با انعطاف پذیری پروسسورهای استاندارد شده XML ترکیب خواهد کرد.
نتیجه: این مقاله اصول وارد کردن داده XML را به پایگاه داده رابطه ای مطرح می کند.
با پذیرفتن سریع XML بعنوان یک شکل از داده، متن های XML بیشتری تجزیه شده و در پایگاه های داده ای با اجرای بالا ذخیره می شوند.
ما با مثالهای ساده و روشن مکانیزمهای عبور از یک مدل XML به یک مدل پایگاه داده را توضیح دادیم.
نتیجه گیری را با دادن چند Java Sample برای وارد کردن ساده ای به یک نگاشت جدولی به کاربر صورت دادیم.
هدف نمایش کد در اینجا بیشتر مطرح کردن رئوس مطالب پیچیدگی Unmarshaling نسبت به یک روش قابل نگهداری قابل استفاده در سیستمهای تولیدی بود.
سفارش ما استفاده از ابزارهای بخش سوم شرکتهایی است که سالها برنامه نویس را برای ارائه یک راه عمومی و آسان اعطا کرده اند به منظور نگاشت هرگونه متن XML به یک پایگاه داده رابطه ای.