در دهه‌های گذشته، ذخیره‌سازی موثر داده‌ها و بدون تناقض آن‌ها جنبه مهم مدیریت داده‌ها بوده است. امروزه مساله ذخیره‌سازی داده‌ها سهم کمتری در میان مساله مدیریت داده‌ها دارد.
تاریخ انتشار: ۲۰:۳۲ - ۱۲ آذر ۱۳۹۵ - 2016 December 02

در دهه‌های گذشته، ذخیره‌سازی موثر داده‌ها و بدون تناقض آن‌ها جنبه مهم مدیریت داده‌ها بوده است. امروزه مساله ذخیره‌سازی داده‌ها سهم کمتری در میان مساله مدیریت داده‌ها دارد. مدیریت داده‌ها و استفاده از آن‌ها حتی نسبت به ده سال قبل، شکل دیگری به خود گرفته است. شبکه‌های اجتماعی، سیستم‌های امنیتی و هوشمند، میزبان‌های رسانه (Media Servers)، دوربین‌های مدار بسته، سیستم‌های مدیریت نقشه‌ها، شبکه‌های سنسوری و… هر یک به نوعی خاص نیازمند استفاده و مدیریت داده‌ها هستند. به عبارتی هر جنبه کیفی استفاده از داده‌ها مانند امنیت و سرعت دسترسی، امکان تغییر و توسعه داده‌ها به شکل‌های گوناگون و… باعث شدند مدل‌های ذخیره‌سازی متفاوتی برای داده‌ها به وجود آید. علاوه بر این موارد، حجم عظیم داده‌های مبادله شده باعث ایجاد مساله‌ای تازه به نام داده‌های بزرگ (BigData) شده است. بنابراین حوزه‌ی مطالعاتی در زمینه‌ی داده‌ها بسیار وسیع است. در این بخش سعی شده که به معرفی اجمالی از چند مدل ذخیره‌سازی داده‌ها و سیستم‌های مدیریت مربوط به آن مدل‌ها پرداخته شود. از آنجا که مدل داده‌ای یک پایگاه‌داده‌ها، رابطه مستقیمی با سیستم مدیریت آن پایگاه داده دارد (البته به جز نوع بدون قالب آن)، در این نوشته گاهی اوقات از واژه «مدل» و «پایگاه‌داده‌ها» به جای «سیستم مدیریت پایگاه‌داده‌ها» استفاده شده است. هرچند که هر کدام مفاهیمی جدا هستند.

سیستم‌های مدیریت پایگاه‌های داده رابطه‌ای (RDBMS):

این مدل را می‌توان جزو پرکاربردترین و شناخته شده‌ترین مدل مدیریت داده‌ها و نیز بالغ‌ترین مدل بین سایر مدل‌ها دانست. شالوده مدل رابطه‌ای، منطق رابطه‌ای است. این منطق توسط ادگار کاد (Edgar Codd)، دانشمند علوم رایانه در سال ۱۹۷۰ معرفی شده و در واقع تفسیر دیگری از نظریه مجموعه‌ها و جبر رابطه‌ای است. هر قلم داده (Data Entity) در مدل رابطه‌ای، معادل یک سطر از جدول است که با یک کلید از سایر سطرهای آن جدول متمایز می‌شود. منطق رابطه‌ای در واقع یک جبر بسته است. به این ترتیب که همه چیز، اعم از جداول و سطرهای جدول، یک رابطه است و حاصل عملگرهای جبری بر روی رابطه‌ها، باز هم یک رابطه است. به خاطر این شالوده‌ قدرتمند، مدل رابطه‌ای توانست جایگزین مدل‌های ناکارآمدی چون مدل سلسله مراتبی و مدل شبکه‌ای شود که پیمایش بین داده‌ها از طریق اشاره‌گرها و زیرروال‌های پیمایشگر صورت می‌گرفت؛ بر خلاف مدل رابطه‌ای که هر سطر به طور منظم و مستقل در جایگاه خود قرار دارد و یافتن آن‌ها نیازمند اشاره‌گرهای نسبی و فراخوانی زیرروال‌های پیمایشگر نیست. بسته بودن منطق رابطه‌ای، باعث به کارگیری پرس‌وجوها (query) به طور تو در تو و به طور موثر می‌شود. در این مدل، عملگرهای رابطه‌ای مانند join، باعث اتصال جدول‌ها با یکدیگر و استفاده‌ی موثر از داده‌ها می‌شود. زبان دستکاری و به کار گیری داده‌ها (DML) در این مدل، معمولا زبان SQL است که یک زبان سطح بالا و اخباری (declarative) است. از آنجا که روند تدریجی توسعه سیستم‌های نرم‌افزاری می‌تواند باعث تغییرات آتی در ساختار پایگاه‌داده‌ها شود، طراحی درست یک پایگاه‌داده‌ها، مساله‌ای ضروری و مهم است. این موضوع در مدل ذخیره‌سازی رابطه‌ای، تا حدودی مساله‌ای چالشی است. گرچه معرفی سطوح نرمال‌سازی و روش‌های نرمال‌سازی پایگاه‌های داده، گام‌های مورد نیاز را برای این امر فراهم می‌آورند، اما طراحی درست و نرمال یک پایگاه‌داده‌های رابطه‌ای خبرگی و مهارت خاص خود را می‌طلبد.
هر دستور یا مجموعه دستورات وابسته به هم که از طریق کاربران به پایگاه‌داده‌های ارسال می‌شود، تحت پوشش یک تراکنش اجرا می‌شود. مدیریت تراکنش‌ها در این نوع شیوه ذخیره‌سازی، مساله‌ای جدای از خود مدل ذخیره‌سازی است؛ به عبارتی سیستم‌های مدیریت پایگاه‌های داده رابطه‌ای (RDBMS) به طور معمول موظفند در زمان اجرای تراکنش‌ها، خواص ACID را به نوعی رعایت و پیاده‌سازی کنند. بدین منظور هر یک از این سیستم‌ها شیوه و سیاست خاص خود را برای مدیریت تراکنش‌ها و پیاده‌سازی خواص ACID عرضه کرده‌اند. سیستم‌هایی مانند MySQL از شیوه قفل‌گذاری در سطح سطرهای جدول به این هدف می‌رسند. اما در سیستمی مثل PostgreSQL، این امکان توسط چند نسخه‌سازی صورت می‌گیرد.

مدل رابطه‌ای دارای محدودیت‌های خاص خود است. کاربر نمی‌تواند به طور معمول و موثر، هر نوع ساختار داده دل‌خواه خود را در یک جدول پایگاه‌داده‌های رابطه‌ای ذخیره کند. به علاوه این که هر RDBMS برای خود مجموعه نوع داده (Data Type)های خود را ارائه کرده است که جدای از ناهمخوانی با یکدیگر، محدود هستند.

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

سیستم‌های مدیریت پایگاه‌های داده شیئ گرا (OODBMS):

اواخر دهه ۸۰ میلادی را می‌توان زمان ظهور پایگاه‌های داده‌ی شئ‌گرا دانست که در واقع پاسخی به نیازمندی‌های برنامه‌های CAD بود که با اشیاء داده‌ی پیچیده و تودرتو سروکار دارند. مساله اینجاست که برنامه‌ی CAD یک برنامه‌ی روالی (procedural) است که در هر لحظه یک ورودی می‌گیرد و یک خروجی پیچیده تولید می‌کند، اما این با ساختار رابطه‌ای در تضاد است و پیاده‌سازی آن در منطق رابطه‌ای مستلزم اجرای دستورات join متعدد و پرس و جو (query)های طولانی، آن هم برای گرفتن تنها یک سطر خروجی است.

سیستم‌های مدیریت پایگاه‌داده‌های شئ‌گرا (OODBMS) برای حل این مشکلات به وجود آمد. خصوصیات این سیستم را می‌توان بطور خلاصه این طور بیان کرد:

پشتیبانی از نوع داده کاربر (User Data Type)
امکان ذخیره‌سازی اشیاء تودرتو
پشتیبانی از لیست اشیاء (مانند مجموعه‌ها، آرایه‌ها، دسته‌ها) و bag (لیستی از لیست‌ها) ، هر کدام به عنوان یک شیئ مستقل
پشتیبانی از متد‌های اشیاء (معادل روال‌های ذخیره شده (Stored Procedure) در پایگاه‌داده‌های رابطه‌ای): متدها جزئی از منطق شئ‌گرا هستند. به جای آن که برنامه درگیر اجرای query جهت دریافت اطلاعات اطلاعات از پایگاه‌داده‌های و محاسبات آن و ارسال نتیجه به پایگاه داده شود، یک متد شئ می‌تواند به طور موثر در سمت سرور پایگاه‌داده‌های اجرا شود و تغییرات را در همان جا، روی شئ اعمال کرده و نتیجه را به برنامه برگرداند.
و یکی از مهم‌ترین خصوصیات این سیستم، اشتراک در نوع داده در برنامه و پایگاه‌داده‌ها است که باعث اعمال قوانین بررسی قوی نوع (Strong Type Checking) در زمان انتقال داده‌ها بین برنامه و پایگاه‌داده‌ها، به طور موثر می‌شود.
ادغام با زبان‌های برنامه‌نویسی: از آنجا که ساختار داده‌ها در پایگاه‌داده‌ها، مانند همان ساختار برنامه کاربر است، ذخیره و بازیابی اطلاعات می‌تواند از طریق دستورات DML درون خود برنامه یا زبان برنامه نویسی صورت بگیرد، به جای آنکه دستورات DML از طریق یک واسطه محدود مانند Connection Stringها یا دستورات خاص، به پایگاه‌داده‌ها، به عنوان یک سیستم جدا ارسال شود.
مشکلات سیستم‌های مدیریت پایگاه‌های داده شئ گرا:

پیمایش بین داده‌ها از طریق روال‌های جداگانه: در منطق پایگاه داده شیئ‌گرا، اشیاء داده به وسیله‌ی اشاره‌گرها به یکدیگر متصل هستند. این منطق وجود یک زیرروال پیمایشگر را موجب می‌شود که می‌توان آن را یک گام به عقب توصیف کرد.
نقض encapsulation: خاصیت encapsulation یکی از پایه‌های مفهوم شیئ‌گرایی است. از آنجا که با اجرای query می‌توان به داده‌های درون یک شئ درون پایگاه‌داده‌ها دست یافت، می‌توان این طور گفت که پایگاه‌داده‌‌ها شئ‌گرا، مفهوم شئ‌گرایی را به طور کامل پشتیبانی نمی‌کنند. گاهی اوقات نقض این encapsulation ضروری است. به عنوان مثال نیازمند داده‌ای از یک شئ داده هستیم که متد آن پیاده‌سازی نشده است و دستیابی به این مقدار، تنها یک بار صورت می‌گیرد. در واقع منطقی نیست که برای دستیابی به این مقدار بخواهیم یک متد جدا درون شئ داده‌ی درون پایگاه‌داده‌ها بنویسیم. بنابراین همواره یک مصالحه بین نقض encapsulation و نوشتن متدهای بیشتر برای اشیاء داده وجود دارد.
بسته بودن جبر رابطه‌ای موجود در منطق رابطه‌ای در اینجا وجود ندارد و به کارگیری پرس‌وجو های تودرتو که حاصل این بسته بودن بود، در اینجا از دست می‌رود. به خصوص که در این مدل، اخباری بودن و سطح بالا بودن زبان دسترسی به داده‌ها (DML) تضعیف می‌شود.
در نهایت آن استخوان‌بندی و شالوده قدرتمند ریاضی که منطق رابطه‌ای بر آن استوار بود، در منطق پایگاه‌داده‌های شئ‌گرا وجود ندارد و این به معنی از دست رفتن مجموعه‌ای از ابزارهای تحلیل و استنتاج مبتنی بر این منطق است.
ایده‌ای که در پشت پیاده‌سازی پایگاه‌داده‌های شئ گرا نهفته بود این بود که برای توسعه‌دهندگان بسیار مفید خواهد بود که نه تنها ذهنشان درگیر پیاده‌سازی پشت رابط اشیاء داده نشود، بلکه حتی درگیر این مساله نباشند که آن شئ چطور در پایگاه‌داده‌ها ذخیره می‌شود.

سه اشتباه که تکرار شد:

شرکت‌های توسعه‌دهنده و پشتیبان ایده پایگاه‌های داده شئ‌گرا متوجه تکرار اشتباه خود شدند.

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

آن‌ها همچنین دوباره فهمیدند که استفاده از زبان‌های اخباری مانند SQL-92 چنان بهره‌وری را بالا می‌برد که شرکت‌های توسعه‌دهنده نرم‌افزار ترجیح می‌دهند که به جای درگیری با مفاهیم جدید، هزینه تامین منابع سخت‌افزاری را پرداخت کنند؛ به عبارتی شما همواره می‌توانید سخت‌افزار بخرید، اما زمان را هرگز!

آن‌ها همچنین دوباره فهمیدند که استاندارد نبودن یک مدل داده‌ای منجر به خطا در طراحی و بروز ناسازگاری در داده‌ها می‌شود. نگهداری از یک سیستم مدیریت پایگاه‌های داده شئ‌گرا کاری بسیار سخت بود.

سیستم مدیریت پایگاه‌های داده شئ-رابطه‌ای (ORDBMS):

گرچه تا سال ۹۵ میلادی، بحث شئ‌گرایی در پایگاه‌های داده مساله داغی بود، اما هنوز یک توافق عام بر سر اینکه یک پایگاه‌داده‌های شئ‌گرا باید شامل چه خصوصیاتی باشد، شکل نگرفت! در نهایت همگان بر این موضوع توافق کردند که پشتیبانی کمی شئ‌گرایی در پایگاه‌های داده بسیار مفید است! به عبارتی گرچه پایگاه‌های داده شئ‌گرا نتوانستند موقیت قابل انتظاری را کسب کنند، اما پیشرو در ارائه چند ایده موفق و کاربردی بودند که بعدها در پایگاه‌داده‌های شئ-رابطه‌ای نیز توانستند پیاده‌سازی شوند. همچنین توسعه‌دهندگان سیستم‌های مدیریت پایگاه‌داده‌های رابطه‌ای نیز متوجه وجود کمبود در این سیستم‌ها شدند، سعی کردند به هر طریقی پشتیبانی از اشیاء داده را در سیستم‌های خود و با رعایت انطباق با نسخه‌های قبلی وارد کنند. که در منبع چهارم این نوشته با دشواری‌های زیاد این رویکرد آشنا خواهید شد. نهایتا گرایش به فواید موجود در مدل‌های ORDBMS و OODBMS باعث به وجود آمدن مفهومی با عنوان پایگاه‌های داده شئ-رابطه‌ای (Object-Relational) شد.

نظر شما
نام:
ایمیل:
* نظر: