طراحی دیتابیس در عصر هوش مصنوعی مولد

هوش مصنوعی مولد چگونه گردش‌کار طراحی دیتابیس را تغییر می‌دهد

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

مثال گردش‌کار با کمک هوش مصنوعی:
۱. اپلیکیشن را به زبان ساده توصیف کن
   ("یک فروشگاه کتاب آنلاین با مشتریان، سفارش‌ها،
    کتاب‌ها، و چند نویسنده به‌ازای هر کتاب")
۲. هوش مصنوعی یک لیست موجودیت کاندید و روابط پیش‌نویس می‌کند
۳. هوش مصنوعی یک اسکیمای نرمال‌شده با کلیدهای اصلی
   و خارجی مناسب پیشنهاد می‌دهد
۴. انسان نتیجه را بررسی، تصحیح، و پالایش می‌کند

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

چرا اسکیماهای تولیدشده توسط هوش مصنوعی همچنان به بررسی دقیق انسانی نیاز دارند

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

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

هر اصلی که در سراسر این مجموعه بحث شد — بررسی ناهنجاری‌ها، تأیید فرم‌های نرمال، تأیید کاردینالیتی رابطه در برابر قوانین کسب‌وکاری واقعی — دقیقاً به‌همان‌اندازه ضروری باقی می‌ماند وقتی یک اسکیمای پیش‌نویس‌شده توسط هوش مصنوعی بررسی می‌شود که وقتی یک اسکیمای کاملاً دستی-پیش‌نویس‌شده بررسی می‌شود. ابزار تغییر کرد؛ قضاوت زیربنایی مورد نیاز برای ارزیابی خروجی‌اش تغییر نکرد.

هوش مصنوعی به‌عنوان یک ابزار برای نوشتن و بهینه‌سازی کوئری

فراتر از طراحی اسکیما، هوش مصنوعی مولد به یک ابزار رایج برای پیش‌نویس کوئری‌های SQL مستقیماً از یک توصیف زبان-ساده از داده مورد نیاز، و برای پیشنهاد ایندکس‌ها یا بازساختاردهی کوئری برای رسیدگی به نگرانی‌های کارایی که پیش‌تر در این مجموعه بحث شد، تبدیل شده است. این می‌تواند توسعه را به‌طور معناداری سرعت بخشد، به‌ویژه برای کوئری‌های پیچیده شامل چند JOIN، اما همان نظم تأیید اعمال می‌شود: یک کوئری پیشنهادی توسط هوش مصنوعی باید برای درستی در برابر اسکیمای واقعی بررسی شود و در برابر داده واقع‌بینانه آزمایش شود، نه اینکه صرفاً چون قابل‌قبول به‌نظر می‌رسد و بدون خطا اجرا می‌شود درست فرض شود.

دیتابیس‌های برداری: یک دسته جدید ساخته‌شده برای اپلیکیشن‌های هوش مصنوعی

فراتر از کمک به طراحی دیتابیس رابطه‌ای سنتی، ظهور هوش مصنوعی یک دسته کاملاً جدید از فناوری دیتابیس معرفی کرده: Vector Database (دیتابیس برداری)، ساخته‌شده به‌طور خاص برای ذخیره و جستجوی کارآمد Embeddings (تعبیه‌ها) — نمایش‌های عددی متن، تصاویر، یا داده‌های دیگر تولیدشده توسط مدل‌های هوش مصنوعی، جایی که آیتم‌های از نظر معنایی مشابه در نهایت با نمایش‌های برداری از نظر ریاضی مشابه ختم می‌شوند.

کوئری رابطه‌ای سنتی:
"همه کتاب‌ها با عنوان دقیق 'Deep Work' را پیدا کن"
→ یک کوئری تطبیق دقیق، به‌خوبی مناسب برای
   یک جستجوی رابطه‌ای ایندکس‌شده سنتی

کوئری دیتابیس برداری:
"کتاب‌هایی که محتوایشان از نظر مفهومی
مشابه این قطعه درباره تمرکز و بهره‌وری است را پیدا کن"
→ یک جستجوی شباهت روی بردارهای با ابعاد بالا،
   نوعی اساساً متفاوت از کوئری که ایندکس‌های
   رابطه‌ای برایش طراحی نشده‌اند

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

دیتابیس‌های برداری چگونه به اصول دیتابیس رابطه‌ای مرتبط‌اند

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

چرا اصول همچنان پایه باقی می‌مانند

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