فصل ۳ — فرایند بازآرایی پایگاه داده

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

— Max Planck

این فصل توضیح می‌دهد چگونه یک بازآرایی منفرد را در پایگاه داده پیاده‌سازی کنید. با مثالی از اعمال Move Column (صفحهٔ ۱۰۳)، یک بازآرایی ساختاری، کار می‌کنیم. اگرچه این بازآرایی ساده به نظر می‌رسد — و هست — خواهید دید پیاده‌سازی امن آن در محیط تولید می‌تواند بسیار پیچیده باشد. شکل ۳.۱ نمای کلی انتقال ستون Customer.Balance به جدول Account را نشان می‌دهد؛ تغییری مستقیم برای بهبود طراحی پایگاه داده.

شکل ۳.۱. انتقال ستون Customer.Balance به Account.

در فصل ۱ «توسعهٔ تکاملی پایگاه داده»، مفهوم sandboxهای کاری منطقی را مرور کردیم — sandboxهای توسعه که توسعه‌دهندگان کپی اختصاصی کد منبع و پایگاه داده دارند؛ محیط یکپارچه‌سازی پروژه که اعضای تیم تغییرات را promote و سپس تست می‌کنند؛ محیط‌های پیش‌تولید برای تست سیستم، یکپارچه‌سازی، و پذیرش کاربر؛ و تولید. کار سخت بازآرایی پایگاه داده در sandbox توسعه انجام می‌شود — در آنجا بررسی، پیاده‌سازی، و تست می‌شود قبل از promote به محیط‌های دیگر. تمرکز این فصل بر کاری است که در sandbox توسعه انجام می‌شود. فصل ۴ «استقرار در تولید» promote و استقرار نهایی بازآرایی‌ها را پوشش می‌دهد.

چون آنچه در sandbox توسعه رخ می‌دهد را توصیف می‌کنیم، این فرایند برای محیط تک‌برنامه‌ای و چندبرنامه‌ای هر دو اعمال می‌شود. تنها تفاوت واقعی بین دو حالت نیاز به دورهٔ گذار طولانی‌تر (بیشتر در ادامه) در سناریوی چندبرنامه‌ای است.

شکل ۳.۲ نمودار فعالیت UML 2 را نشان می‌دهد که فرایند بازآرایی پایگاه داده را مرور می‌کند. فرایند با توسعه‌دهنده‌ای شروع می‌شود که سعی می‌کند نیازمندی جدیدی پیاده کند یا نقصی را برطرف کند. توسعه‌دهنده می‌فهمد طرحوارهٔ پایگاه داده شاید نیاز به بازآرایی دارد. در این مثال، Eddy — یک توسعه‌دهنده — نوع جدیدی از تراکنش مالی به برنامهٔ خود اضافه می‌کند و می‌فهمد ستون Balance در واقع موجودیت‌های Account را توصیف می‌کند، نه Customer. چون Eddy شیوه‌های چابک رایج مانند برنامه‌نویسی جفتی (pair programming) (Williams & Kessler 2002) و مدل‌سازی با دیگران (Ambler 2002) را دنبال می‌کند، تصمیم می‌گیرد از Beverley — DBA تیم — برای اعمال بازآرایی کمک بگیرد. با هم به‌صورت تکراری این فعالیت‌ها را انجام می‌دهند:

شکل ۳.۲. فرایند بازآرایی پایگاه داده.

• تأیید کنید بازآرایی پایگاه داده مناسب است.
• مناسب‌ترین بازآرایی پایگاه داده را انتخاب کنید.
• طرحوارهٔ اصلی پایگاه داده را منسوخ (deprecate) کنید.
• قبل، حین، و بعد تست کنید.
• طرحوارهٔ پایگاه داده را تغییر دهید.
• دادهٔ منبع را مهاجرت دهید.
• برنامه(های) دسترسی بیرونی را تغییر دهید.
• تست‌های رگرسیون را اجرا کنید.
• کار خود را تحت کنترل نسخه قرار دهید.
• بازآرایی را اعلام کنید.

۳.۱. تأیید مناسب بودن بازآرایی پایگاه داده

ابتدا Beverley تعیین می‌کند آیا بازآرایی پیشنهادی لازم است. سه مسئله را باید در نظر گرفت:

1. آیا بازآرایی منطقی است؟

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

2. آیا تغییر واقعاً اکنون لازم است؟

   این معمولاً تصمیم شهودی (gut call) بر اساس تجربهٔ قبلی Beverley با توسعه‌دهندهٔ برنامه است. آیا Eddy دلیل خوبی برای تغییر طرحواره دارد؟ آیا می‌تواند نیازمندی کسب‌وکار را که تغییر از آن پشتیبانی می‌کند توضیح دهد؟ آیا نیازمندی درست به نظر می‌رسد؟ آیا Eddy در گذشته تغییرات خوبی پیشنهاد داده؟ آیا چند روز بعد نظرش عوض شده و Beverley مجبور شده تغییر را برگرداند؟ بسته به این ارزیابی، Beverley ممکن است پیشنهاد دهد Eddy بیشتر فکر کند، یا تصمیم بگیرد با او ادامه دهد اما مدت بیشتری صبر کند قبل از اعمال واقعی تغییر در محیط یکپارچه‌سازی پروژه (فصل ۴) اگر فکر کند تغییر باید برگردانده شود.

3. آیا ارزش تلاش را دارد؟

   کار بعدی Beverley ارزیابی اثر کلی بازآرایی است. برای این کار باید درک کند برنامه(های) بیرونی چگونه به این بخش از پایگاه داده جفت‌اند. این دانشی است که Beverley با کار با معماران سازمانی، DBAهای عملیاتی، توسعه‌دهندگان برنامه، و سایر DBAها در طول زمان ساخته. وقتی Beverley از اثر مطمئن نیست، باید در همان لحظه تصمیم بگیرد و به شهودش تکیه کند، یا به توسعه‌دهندهٔ برنامه بگوید صبر کند تا با افراد مناسب صحبت کند. هدفش اطمینان از پیاده‌سازی بازآرایی‌هایی است که موفق می‌شوند — اگر برای پشتیبانی از این بازآرایی باید ۵۰ برنامهٔ دیگر را به‌روز، تست، و دوباره مستقر کنید، شاید ادامه دادن عملی نباشد. حتی وقتی فقط یک برنامه به پایگاه داده دسترسی دارد، ممکن است آن‌قدر به بخشی از طرحواره که می‌خواهید تغییر دهید جفت باشد که بازآرایی اصلاً ارزش نداشته باشد. در مثال ما، مشکل طراحی آن‌قدر واضح و شدید است که تصمیم می‌گیرد پیاده‌سازی کند حتی اگر برنامه‌های زیادی تحت تأثیر قرار گیرند.

گام‌های کوچک بردارید

بازآرایی پایگاه داده طرحواره را در گام‌های کوچک تغییر می‌دهد؛ هر بازآرایی باید یک‌بار یک‌بار انجام شود. مثلاً فرض کنید می‌فهمید باید ستون موجود را منتقل کنید، نامش را عوض کنید، و قالب مشترک اعمال کنید. به‌جای انجام همهٔ این‌ها یک‌جا، باید ابتدا Move Column (صفحهٔ ۱۰۳) را با موفقیت پیاده کنید، سپس Rename Column (صفحهٔ ۱۰۹)، و سپس Introduce Common Format (صفحهٔ ۱۸۳) را یک‌گام‌یک‌گام. مزیت این است که اگر اشتباه کنید، پیدا کردن باگ آسان است چون احتمالاً در همان بخشی از طرحواره است که تازه تغییر داده‌اید.

۳.۲. انتخاب مناسب‌ترین بازآرایی پایگاه داده

همان‌طور که در این کتاب می‌بینید، تعداد زیادی بازآرایی بالقوه روی طرحوارهٔ پایگاه داده می‌توانید اعمال کنید. برای تعیین مناسب‌ترین بازآرایی برای موقعیت خود، ابتدا باید مسئله‌ای که با آن روبه‌رو هستید را تحلیل و بفهمید. وقتی Eddy برای اولین بار به Beverley مراجعه کرد، شاید این تحلیل را انجام نداده باشد. مثلاً شاید فقط گفته باشد جدول Account باید موجودی فعلی را ذخیره کند؛ بنابراین باید ستون جدید اضافه کنیم (از طریق تبدیل Introduce Column در صفحهٔ ۱۸۰). اما آنچه نفهمیده بود این است که ستون از قبل در جدول Customer وجود دارد — که احتمالاً جای اشتباهی برای آن است. Eddy مسئله را درست شناسایی کرده بود، اما راه‌حل را اشتباه. بر اساس دانش Beverley از طرحوارهٔ موجود و درک مسئله‌ای که Eddy شناسایی کرده، Beverley پیشنهاد می‌کند Move Column (صفحهٔ ۱۰۳) را اعمال کنند.

گاهی داده جای دیگری است

پایگاه دادهٔ شما احتمالاً تنها منبع داده در سازمان نیست. DBA خوب باید حداقل از منابع دادهٔ مختلف سازمان — اگر نه درک کامل — آگاه باشد تا بهترین منبع داده را تعیین کند. در مثال ما، پایگاه دادهٔ دیگری می‌تواند مخزن رسمی اطلاعات Account باشد. اگر چنین باشد، انتقال ستون شاید منطقی نباشد چون بازآرایی واقعی Use Official Data Source (صفحهٔ ۲۷۱) خواهد بود.

۳.۳. منسوخ کردن طرحوارهٔ اصلی پایگاه داده

اگر چند برنامه به پایگاه داده دسترسی دارند، احتمالاً باید فرض کنید نمی‌توانید همهٔ این برنامه‌ها را هم‌زمان بازآرایی و مستقر کنید. در عوض به دورهٔ گذار — که دورهٔ منسوخ‌سازی (deprecation period) هم نامیده می‌شود — برای بخش اصلی طرحواره که تغییر می‌دهید نیاز دارید (Sadalage & Schuh 2002; Ambler 2003). در دورهٔ گذار، هر دو نسخهٔ طرحوارهٔ اصلی و جدید را موازی پشتیبانی می‌کنید تا تیم‌های برنامهٔ دیگر فرصت بازآرایی و استقرار مجدد سیستم‌هایشان را داشته باشند. دوره‌های گذار معمول چند فصل، اگر نه سال، طول می‌کشند. زمان بالقوهٔ طولانی برای پیاده‌سازی کامل یک بازآرایی نیاز به خودکارسازی تا حد ممکن فرایند را برجسته می‌کند. در طول چند سال، افراد در بخش عوض می‌شوند و اگر بخش‌هایی از فرایند دستی باشند در معرض ریسک قرار می‌گیرید. با این حال، حتی در پایگاه دادهٔ تک‌برنامه‌ای، تیم شما ممکن است هنوز دورهٔ گذار چندروزه‌ای در sandbox یکپارche‌سازی پروژه لازم داشته باشد — هم‌تیمی‌ها باید کد را بازآرایی و دوباره تست کنند تا با طرحوارهٔ به‌روز پایگاه داده کار کند.

شکل ۳.۳ چرخهٔ عمر یک بازآرایی پایگاه داده در سناریوی چندبرنامه‌ای را نشان می‌دهد. ابتدا آن را در محدودهٔ پروژهٔ خود پیاده می‌کنید و اگر موفق بود، در نهایت در تولید مستقر می‌کنید. در دورهٔ گذار، هم طرحوارهٔ اصلی و هم جدید وجود دارند، با کد scaffolding کافی برای اطمینان از پشتیبانی درست به‌روزرسانی‌ها. در دورهٔ گذار باید دو فرض کنید: اول، برخی برنامه‌ها از طرحوارهٔ اصلی و برخی از جدید استفاده می‌کنند؛ دوم، برنامه‌ها باید فقط با یکی از دو نسخه کار کنند، نه هر دو هم‌زمان. در مثال ما، برخی برنامه‌ها با Customer.Balance و برخی با Account.Balance کار می‌کنند، اما نه هر دو هم‌زمان. صرف‌نظر از ستونی که با آن کار می‌کنند، همهٔ برنامه‌ها باید درست اجرا شوند. وقتی دورهٔ گذار تمام شد، طرحوارهٔ اصلی به‌علاوهٔ هر کد scaffolding حذف می‌شود و پایگاه داده دوباره تست می‌شود. در این نقطه فرض می‌شود همهٔ برنامه‌ها با Account.Balance کار می‌کنند.

شکل ۳.۳. چرخهٔ عمر بازآرایی پایگاه داده در سناریوی چندبرنامه‌ای.

شکل ۳.۴ طرحوارهٔ اصلی پایگاه داده را نشان می‌دهد و شکل ۳.۵ آنچه طرحواره در دورهٔ گذار هنگام اعمال بازآرایی Move Column روی Customer.Balance خواهد بود. در شکل ۳.۵، تغییرات پررنگ نشان داده شده — سبکی که در سراسر کتاب استفاده می‌کنیم. توجه کنید هر دو نسخهٔ طرحواره در این دوره پشتیبانی می‌شوند. Account.Balance به‌عنوان ستون اضافه شده و Customer.Balance برای حذف در یا پس از ۱۴ ژوئن ۲۰۰۶ علامت‌گذاری شده. trigger هم برای همگام نگه‌داشتن مقادیر دو ستون معرفی شده — با فرض اینکه کد برنامهٔ جدید با Account.Balance کار می‌کند اما Customer.Balance را به‌روز نمی‌کند. به‌طور مشابه، فرض می‌کنیم کد برنامهٔ قدیمی‌تر که برای طرحوارهٔ جدید بازآرایی نشده نمی‌داند Account.Balance را به‌روز کند. این trigger نمونه‌ای از کد scaffolding پایگاه داده است — کد ساده و رایج لازم برای «چسباندن» پایگاه داده. این کد همان تاریخ حذف Customer.Balance را دارد.

شکل ۳.۴. طرحوارهٔ اصلی Customer/Account.

شکل ۳.۵. پشتیبانی از هر دو نسخهٔ طرحواره.

همهٔ بازآرایی‌های پایگاه داده به دورهٔ گذار نیاز ندارند. مثلاً نه Introduce Column Constraint (صفحهٔ ۱۸۰) و نه Apply Standard Codes (صفحهٔ ۱۵۷) به دورهٔ گذار نیاز دارند چون صرفاً با محدود کردن مقادیر قابل قبول در ستون کیفیت داده را بهبود می‌دهند. با این حال، محدودیت باریک‌تر ممکن است برنامه‌های موجود را بشکند؛ پس از این بازآرایی‌ها احتیاط کنید.

فصل ۵ «راهبردهای بازآرایی پایگاه داده» راهبردهای انتخاب دورهٔ گذار مناسب را بحث می‌کند.

۳.۴. تست قبل، حین، و بعد

اگر بتوانید به‌راحتی تأیید کنید پس از تغییر پایگاه داده هنوز با برنامه کار می‌کند، جسارت تغییر طرحواره را خواهید داشت — و تنها راه این است که رویکرد توسعهٔ رانش‌محور تست (Test-Driven Development — TDD) را بپذیرید، همان‌طور که در فصل ۱ پیشنهاد شد. با رویکرد مبتنی بر TDD، ابتدا تست می‌نویسید و سپس فقط به اندازهٔ کافی کد — اغلب data definition language (DDL) — برای برآورده کردن تست. تا پیاده‌سازی کامل بازآرایی پایگاه داده ادامه می‌دهید. احتمالاً باید تست‌هایی بنویسید که موارد زیر را انجام دهند:

• طرحوارهٔ پایگاه داده را تست کنند.
• نحوهٔ استفادهٔ برنامه از طرحواره را تست کنند.
• مهاجرت داده را اعتبارسنجی کنند.
• کد برنامهٔ بیرونی را تست کنند.

۳.۴.۱. تست طرحوارهٔ پایگاه داده

چون بازآرایی پایگاه داده بر طرحواره تأثیر می‌گذارد، باید تست‌های متمرکز بر پایگاه داده بنویسید. اگرچه در ابتدا عجیب به نظر می‌رسد، می‌توانید بسیاری از جنبه‌های طرحواره را اعتبارسنجی کنید:

• Stored procedureها و triggerها. stored procedureها و triggerها باید مثل کد برنامه تست شوند.

• یکپارچگی ارجاعی (RI). قواعد RI، به‌ویژه حذف آبشاری (cascading delete) که ردیف‌های «فرزند» highly coupled هنگام حذف ردیف والد حذف می‌شوند، باید اعتبارسنجی شوند. قواعد وجود — مثلاً ردیف مشتری متناظر با ردیف حساب باید قبل از درج در جدول Account وجود داشته باشد — هم به‌راحتی قابل تست‌اند.

• تعاریف view. viewها اغلب منطق کسب‌وکار جالبی پیاده می‌کنند. موارد قابل توجه: آیا منطق فیلتر/انتخاب درست کار می‌کند؟ آیا تعداد ردیف درست برمی‌گردد؟ آیا ستون‌های درست برمی‌گردند؟ آیا ستون‌ها و ردیف‌ها در ترتیب درست هستند؟

• مقادیر پیش‌فرض. ستون‌ها اغلب مقادیر پیش‌فرض دارند. آیا واقعاً اختصاص داده می‌شوند؟ (شاید کسی این بخش از تعریف جدول را تصادفاً حذف کرده باشد.)

• ناوردهای داده (data invariants). ستون‌ها اغلب ناوردهایی — به‌صورت constraint — دارند. مثلاً ستون عددی ممکن است به مقادیر ۱ تا ۷ محدود شود. این ناوردها باید تست شوند.

تست پایگاه داده برای بسیاری جدید است و در نتیجه هنگام پذیرش بازآرایی پایگاه داده به‌عنوان تکنیک توسعه با چند چالش روبه‌رو می‌شوید:

• مهارت تست ناکافی. این مشکل با آموزش، جفت شدن با کسی که مهارت تست خوب دارد (جفت DBA بدون مهارت تست با tester بدون مهارت DBA هم جواب می‌دهد)، یا آزمون و خطا قابل رفع است. مهم این است که بپذیرید باید این مهارت‌ها را کسب کنید.

• تست واحد ناکافی برای پایگاه داده. سازمان‌های کمی هنوز practice تست پایگاه داده را پذیرفته‌اند؛ پس احتمالاً مجموعهٔ تست کافی برای طرحوارهٔ موجود ندارید. اگرچه این بدشانسی است، بهتر از همه زمان برای شروع نوشتن مجموعهٔ تست، همین حالاست.

• ابزار تست پایگاه داده ناکافی. خوشبختانه ابزارهایی مانند DBUnit (dbunit.sourceforge.net) برای مدیریت دادهٔ آزمون و SQLUnit (sqlunit.sourceforge.net) برای تست stored procedure به‌صورت نرم‌افزار متن‌باز (OSS) در دسترس‌اند. علاوه بر این، چند ابزار تجاری برای تست پایگاه داده وجود دارد. با این حال، در زمان نگارش این کتاب، هنوز فرصت قابل توجهی برای بهبود پیشنهادات تست پایگاه داده توسط فروشندگان ابزار وجود دارد.

پس چگونه تغییرات طرحواره را تست می‌کنیم؟ همان‌طور که در شکل ۳.۵ می‌بینید، در دورهٔ گذار دو تغییر در طرحواره باید اعتبارسنجی شوند. اولی افزودن ستون Balance به جدول Account است — که با تلاش‌های مهاجرت داده و تست برنامهٔ بیرونی — که در بخش‌های بعد بحث می‌شود — پوشش داده می‌شود. تغییر دوم افزودن دو trigger، SynchronizeAccountBalance و SynchronizeCustomerBalance است که — همان‌طور که نامشان نشان می‌دهد — دو ستون داده را همگام نگه می‌دارند. باید تست‌هایی داشته باشیم که اگر Customer.Balance به‌روز شود، Account.Balance هم به‌روز شود و بالعکس.

۳.۴.۲. اعتبارسنجی مهاجرت داده

بسیاری از بازآرایی‌های پایگاه داده نیاز دارید دادهٔ منبع را مهاجرت دهید و گاهی حتی پاکسازی (cleanse) کنید. در مثال ما باید مقادیر داده را از Customer.Balance به Account.Balance در بخشی از پیاده‌سازی بازآرایی کپی کنیم. در این حالت می‌خواهیم تأیید کنیم موجودی درست برای مشتریان منفرد در واقع کپی شده.

در بازآرایی‌هایی مانند Apply Standard Codes (صفحهٔ ۱۵۷) و Consolidate Key Strategy (صفحهٔ ۱۶۸)، در واقع مقادیر داده را «پاکسازی» می‌کنید. این منطق پاکسازی باید اعتبارسنجی شود. در بازآرایی اول، شاید مقادیر کد مانند USA و U.S. را در سراسر پایگاه داده به مقدار استاندارد US تبدیل کنید. می‌خواهید تست بنویسید که کدهای قدیمی دیگر استفاده نمی‌شوند و به درستی به مقدار رسمی تبدیل شده‌اند. در بازآرایی دوم، شاید بفهمید مشتریان در برخی جداول با شناسهٔ مشتری، در برخی با شماره تأمین اجتماعی (SSN)، و در برخی با شماره تلفن شناسایی می‌شوند. می‌خواهید یک روش برای شناسایی مشتری — شاید شناسهٔ مشتری — انتخاب کنید و سپس جداول دیگر را بازآرایی کنید تا از این نوع ستون استفاده کنند. در این حالت می‌خواهید تست بنویسید که رابطهٔ بین ردیف‌های مختلف هنوز درست حفظ می‌شود. (مثلاً اگر شماره تلفن 555-1234 به رکورد مشتری Sally Jones ارجاع می‌داد، پس از جایگزینی با شناسهٔ مشتری 987654321، رکورد Sally Jones هنوز باید ارجاع داده شود.)

۳.۴.۳. تست برنامه(های) دسترسی بیرونی

پایگاه دادهٔ شما توسط یک یا چند برنامه — از جمله برنامه‌ای که روی آن کار می‌کنید — دسترسی داده می‌شود. این برنامه‌ها باید مثل هر دارایی IT دیگر در سازمان اعتبارسنجی شوند. برای بازآرایی موفق پایگاه داده، باید بتوانید طرحوارهٔ نهایی — که در شکل ۳.۶ نشان داده شده — را معرفی کنید و ببینید در برنامه‌های دسترسی بیرونی چه چیزی می‌شکند. تنها راه داشتن جسارت بازآرایی طرحواره، داشتن مجموعهٔ تست رگرسیون کامل برای این برنامه‌هاست — بله، می‌دانیم احتمالاً این مجموعه‌ها را ندارید. باز هم، بهتر از همه زمان برای شروع ساخت مجموعهٔ تست، همین حالاست. پیشنهاد می‌کنیم تمام کد تست لازم برای پشتیبانی از هر بازآرایی پایگاه داده منفرد برای همهٔ برنامه‌های دسترسی بیرونی بنویسید. (در واقع، مالکان این سیستم‌ها باید آن تست‌ها را بنویسند، نه شما.) اگر این‌طور کار کنید، در طول زمان مجموعهٔ تست مورد نیاز را می‌سازید.

شکل ۳.۶. نسخهٔ نهایی طرحوارهٔ پایگاه داده.

۳.۵. تغییر طرحوارهٔ پایگاه داده

Eddy و Beverley با هم تغییرات را در sandbox توسعه اعمال می‌کنند. همان‌طور که در شکل ۳.۵ می‌بینید، باید ستون Account.Balance و دو trigger، SynchronizeAccountBalance و SynchronizeCustomerBalance را اضافه کنند. کد DDL برای این کار اینجا نشان داده شده:

ALTER TABLE Account ADD Balance Numeric;
COMMENT ON Account.Balance 'Move of Customer.Balance column, finaldate = 2006-06-14';

CREATE OR REPLACE TRIGGER SynchronizeCustomerBalance
  BEFORE INSERT OR UPDATE
 ON Account
  REFERENCING OLD AS OLD NEW AS NEW
  FOR EACH ROW
  DECLARE
 BEGIN
   IF :NEW.Balance IS NOT NULL THEN
    UpdateCustomerBalance;
   END IF;
 END;
/
COMMENT ON SynchronizeCustomerBalance 'Move of Customer.Balance column to Account,
dropdate = 2006-06-14';

CREATE OR REPLACE TRIGGER SynchronizeAccountBalance
  BEFORE INSERT OR UPDATE OR DELETE
 ON Customer
  REFERENCING OLD AS OLD NEW AS NEW
  FOR EACH ROW
  DECLARE
 BEGIN
   IF DELETING THEN
    DeleteCustomerIfAccountNotFound;
   END IF;
   IF (UPDATING OR INSERTING) THEN
    IF :NEW.Balance IS NOT NULL THEN
     UpdateAccountBalanceForCustomer;
    END IF;
   END IF;
 END;
/
COMMENT ON SynchronizeAccountBalance 'Move of Customer.Balance column to Account,
dropdate = 2006-06-14'

در زمان نگارش این کتاب، ابزار خودکار بازآرایی پایگاه داده در دسترس نیست — بنابراین فعلاً باید همه‌چیز را دستی کدنویسی کنید. نگران نباشید. این با گذشت زمان تغییر خواهد کرد. فعلاً می‌خواهید یک اسکریپت واحد حاوی کد پیشین بنویسید که روی طرحوارهٔ پایگاه داده اعمال کنید. پیشنهاد می‌کنیم به هر اسکریپت شمارهٔ یکتا و افزایشی اختصاص دهید. ساده‌ترین روش: از عدد یک شروع کنید و هر بار که بازآرایی پایگاه داده جدید تعریف می‌کنید شمارنده را افزایش دهید — ساده‌ترین راه استفاده از build number برنامه است. با این حال، برای کار در محیط چندتیمی، به روشی برای اختصاص شماره‌های یکتا در همهٔ تیم‌ها یا افزودن شناسهٔ یکتای تیم به بازآرایی‌های منفرد نیاز دارید. اساساً باید بتوانید بین بازآرایی شمارهٔ ۱۷۰۱ تیم A و بازآرایی شمارهٔ ۱۷۰۱ تیم B تمایز قائل شوید. گزینهٔ دیگر — که در فصل ۵ با جزئیات بیشتر بحث می‌شود — اختصاص timestamp به بازآرایی است.

چند دلیل برای کار با اسکریپت‌های کوچک برای بازآرایی‌های منفرد وجود دارد:

• سادگی. اسکریپت‌های تغییر کوچک و متمرکز نگه‌داری‌شان از اسکریپت‌های چندمرحله‌ای آسان‌تر است. اگر بفهمید بازآرایی نباید انجام شود — شاید به‌دلیل مشکلات پیش‌بینی‌نشده (مثلاً نمی‌توانید برنامهٔ اصلی که به بخش تغییر‌یافتهٔ طرحواره دسترسی دارد به‌روز کنید) — می‌خواهید به‌راحتی آن بازآرایی را انجام ندهید.

• درستی. می‌خواهید هر بازآرایی را — به ترتیب مناسب — روی طرحواره اعمال کنید تا آن را به‌شکل تعریف‌شده تکامل دهید. بازآرایی‌ها می‌توانند روی یکدیگر بنا شوند. مثلاً شاید ستونی را rename کنید و چند هفته بعد به جدول دیگر منتقل کنید. بازآرایی دوم به اول وابسته است چون کد آن به نام جدید ستون اشاره می‌کند.

• نسخه‌بندی. نمونه‌های مختلف پایگاه داده نسخه‌های مختلف طرحواره دارند. مثلاً sandbox توسعهٔ Eddy ممکن است نسخهٔ ۱۶۳، sandbox یکپارche‌سازی پروژه نسخهٔ ۱۶۱، sandbox QA/Test نسخهٔ ۱۵۵، و پایگاه دادهٔ تولید نسخهٔ ۱۳۴ داشته باشد. برای مهاجرت طرحوارهٔ sandbox یکپارche‌سازی پروژه به نسخهٔ ۱۶۳، باید فقط بازآرایی‌های ۱۶۲ و ۱۶۳ را اعمال کنید. برای ردیابی شمارهٔ نسخه، باید جدول مشترکی — مانند DatabaseConfiguration — معرفی کنید که شمارهٔ نسخهٔ فعلی و موارد دیگر را ذخیره کند. این جدول در فصل ۵ با جزئیات بیشتر بحث می‌شود.

کد DDL زیر باید پس از پایان دورهٔ گذار (بحث در فصل ۴) روی پایگاه داده اجرا شود. به‌طور مشابه، این کد باید در یک فایل اسکریپت واحد — همراه با شناسهٔ ۱۶۳ در این مثال — گرفته شود و به ترتیب متوالی روی طرحواره اعمال شود:

ALTER TABLE Customer DROP COLUMN Balance;
DROP TRIGGER SynchronizeAccountBalance;
DROP TRIGGER SynchronizeCustomerBalance;

قراردادهای طراحی پایگاه داده را رعایت کنید

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

۳.۶. مهاجرت دادهٔ منبع

بسیاری از بازآرایی‌های پایگاه داده نیاز دارید دادهٔ منبع را به‌نوعی دستکاری کنید. گاهی فقط باید داده را از یک مکان به دیگری منتقل کنید — کاری که با Move Data (صفحهٔ ۱۹۲) باید انجام دهیم. گاهی باید مقادیر داده را پاکسازی کنید؛ این در بازآرایی‌های کیفیت داده (فصل ۷ «بازآرایی‌های کیفیت داده») مانند Apply Standard Type (صفحهٔ ۱۶۲) و Introduce Common Format (صفحهٔ ۱۸۳) رایج است.

مشابه تغییر طرحوارهٔ پایگاه داده، احتمالاً باید اسکریپتی برای مهاجرت دادهٔ لازم بسازید. این اسکریپت باید همان شمارهٔ شناسایی اسکریپت دیگر را داشته باشد تا مدیریت آسان باشد. در مثال انتقال ستون Customer.Balance به Account، اسکریپت مهاجرت داده باید کد data manipulation language (DML) زیر را داشته باشد:

/*
One time migration of data from Customer.Balance to Account.Balance.
*/

UPDATE Account SET Balance =
 (SELECT Balance FROM Customer
  WHERE CustomerID = Account.CustomerID);

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

نیاز به مستندسازی نشان‌دهندهٔ نیاز به بازآرایی است

وقتی می‌یابید باید مستندسازی پشتیبان برای توصیف جدول، ستون، یا stored procedure بنویسید، نشانهٔ خوبی است که باید آن بخش از طرحواره را بازآرایی کنید تا فهم آسان‌تر شود. شاید یک rename ساده بتواند از چند پاراگراف مستندسازی جلوگیری کند. هرچه طراحی تمیزتر باشد، مستندسازی کمتری لازم است.

۳.۷. بازآرایی برنامه(های) دسترسی بیرونی

وقتی طرحوارهٔ پایگاه داده تغییر می‌کند، اغلب باید هر برنامهٔ بیرونی موجود که به بخش تغییر‌یافتهٔ طرحواره دسترسی دارد را بازآرایی کنید. همان‌طور که در فصل ۲ «بازآرایی پایگاه داده» آموختید، این شامل برنامه‌های legacy، چارچوب‌های persistence، کد replication داده، و سیستم‌های گزارش‌گیری است.

چند کتاب خوب راهنمایی برای بازآرایی مؤثر برنامه‌های دسترسی بیرونی ارائه می‌دهند:

• Refactoring: Improving the Design of Existing Code (Fowler 1999) متن کلاسیک این موضوع است.

• Working Effectively with Legacy Code (Feathers 2004) توضیح می‌دهد چگونه سیستم‌های legacy که سال‌ها در سازمان وجود داشته‌اند را بازآرایی کنید.

• Refactoring to Patterns (Kerievsky 2004) توضیح می‌دهد چگونه به‌صورت منظم کد را بازآرایی کنید تا الگوهای طراحی و معماری رایج را پیاده کنید.

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

هدف: توسعهٔ پیوسته

ایده‌آل این است که سازمان شما به‌طور پیوسته روی همهٔ برنامه‌ها کار کند، آن‌ها را در طول زمان تکامل دهد، و به‌طور منظم مستقر کند. اگرچه این پیچیده به نظر می‌رسد — و می‌تواند باشد — آیا بخش IT نباید فعالانه تلاش کند سیستم‌های سازمان نیازهای در حال تغییر را برآورده کنند؟ در چنین محیط‌هایی می‌توانید دورهٔ گذار نسبتاً کوتاه داشته باشید چون می‌دانید همهٔ برنامه‌های دسترسی به پایگاه داده به‌طور منظم تکامل می‌یابند و بنابراین می‌توانند برای کار با طرحوارهٔ تغییر‌یافته به‌روز شوند.

پس وقتی بودجه‌ای برای به‌روزرسانی برنامه‌های بیرونی نیست چه می‌کنید؟ دو استراتژی اصلی دارید. اول، بازآرایی پایگاه داده را انجام دهید و دورهٔ گذار چند دهه‌ای به آن اختصاص دهید. این‌طور برنامه‌های بیرونی که نمی‌توانید تغییر دهید هنوز کار می‌کنند؛ اما برنامه‌های دیگر می‌توانند به طراحی بهبود‌یافته دسترسی داشته باشند. این استراتژی متأسفانه عیب دارد که کد scaffolding برای پشتیبانی از هر دو طرحواره مدت طولانی وجود دارد، عملکرد پایگاه داده را کاهش می‌دهد و آن را شلوغ می‌کند. استراتژی دوم: بازآرایی را انجام ندهید.

۳.۸. اجرای تست‌های رگرسیون

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

۳.۹. کنترل نسخهٔ کار خود

وقتی بازآرایی پایگاه داده موفق بود، باید همهٔ کار را تحت کنترل مدیریت پیکربندی (configuration management — CM) با check-in به ابزار کنترل نسخه قرار دهید. اگر مصنوعات متمرکز بر پایگاه داده را دقیقاً مثل کد منبع رفتار کنید، مشکلی نخواهید داشت. مصنوعاتی که باید تحت کنترل نسخه قرار گیرند:

• هر اسکریپتی که ساخته‌اید
• دادهٔ آزمون و/یا کد تولید آن
• موارد تست (test cases)
• مستندسازی
• مدل‌ها

۳.۱۰. اعلام بازآرایی

پایگاه داده یک منبع مشترک است. حداقل در تیم توسعهٔ برنامهٔ شما — اگر نه چند تیم برنامه — به اشتراک گذاشته می‌شود. بنابراین باید به طرف‌های علاقه‌مند اعلام کنید بازآرایی پایگاه داده انجام شده. اوایل چرخهٔ عمر بازآرایی، باید تغییرات را در تیم اعلام کنید — که می‌تواند به‌سادگی اعلام در جلسهٔ standup بعدی تیم باشد. در محیط چندبرنامه‌ای، باید تغییرات را به تیم‌های دیگر اعلام کنید — به‌ویژه وقتی تصمیم می‌گیرید بازآرایی را به محیط‌های تست پیش‌تولید promote کنید. این ارتباط می‌تواند ایمیل ساده روی لیست پستی داخلی مخصوص اعلام تغییرات پایگاه داده، یک مورد در گزارش وضعیت منظم پروژه، یا گزارش رسمی به گروه Database Administration عملیاتی باشد.

جنبهٔ مهمی از تلاش‌های اعلام، به‌روزرسانی هر مستندسازی مرتبط خواهد بود. این مستندسازی در تلاش‌های promote و استقرار (فصل ۴) حیاتی است چون تیم‌های دیگر باید بدانند طرحواره چگونه تکامل یافته. رویکرد ساده: یادداشت‌های انتشار پایگاه داده (database release notes) بسازید که تغییرات را خلاصه می‌کنند و هر بازآرایی پایگاه داده را به ترتیب فهرست می‌کنند. بازآرایی مثال ما در این فهرست به‌صورت «163: انتقال ستون Customer.Balance به جدول Account» ظاهر می‌شود. این یادداشت‌های انتشار احتمالاً توسط مدیران سازمانی لازم است تا متادیتای مرتبط را به‌روز کنند. (بهتر است تیم شما این متادیتا را بخشی از تلاش‌های بازآرایی به‌روز کند.)

می‌خواهید مدل دادهٔ فیزیکی (PDM) پایگاه داده را به‌روز کنید. PDM مدل اصلی توصیف‌کنندهٔ طرحوارهٔ پایگاه داده است و اغلب یکی از معدود مدل‌های «نگهداری‌شده» (keeper) در پروژه‌های توسعهٔ برنامه است؛ بنابراین باید تا حد ممکن به‌روز بماند.

مدل‌های داده را زود منتشر نکنید

طرحواره‌های شیء و پایگاه دادهٔ شما در ابتدا احتمالاً نوسان دارند چون با رویکرد تکاملی به توسعه، طراحی در طول زمان ظهور می‌کند. به‌خاطر این نوسان اولیه، باید صبر کنید تا بخش‌های جدید طرحواره پایدار شوند قبل از انتشار به‌روزرسانی‌های PDM. این تلاش مستندسازی را کاهش می‌دهد و اثر روی تیم‌های برنامهٔ دیگر که به طرحوارهٔ پایگاه دادهٔ شما متکی‌اند را به حداقل می‌رساند.

۳.۱۱. آنچه آموختید

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

برای پیاده‌سازی بازآرایی، باید رویکرد تست‌اول (Test-First) بپذیرید تا احتمال کشف شکست‌های معرفی‌شده توسط بازآرایی بیشتر شود. باید طرحوارهٔ پایگاه داده را تغییر دهید، احتمالاً دادهٔ منبع مرتبط را مهاجرت دهید، و سپس هر برنامهٔ بیرونی که به طرحواره دسترسی دارد را تغییر دهید. همهٔ کار باید تحت کنترل نسخه باشد، و پس از پیاده‌سازی در محیط توسعه، باید به هم‌تیمی‌ها و در نهایت تیم‌های بیرونی مناسب که شاید به تغییر طرحواره نیاز داشته باشند اعلام شود.