اشتباهات رایج در طراحی دیتابیس که باید از آنها دوری کنیم!

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

انواع اشتباهات رایج در طراحی دیتابیس

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

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

1. برنامه ریزی ضعیف

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

قبل از این که دست به ترسیم مدل داده بزنید، باید مطمئن شوید که:

• شما به صورت کامل از کارهایی که مشتری انجام می دهد (یعنی بیزینس پلن های مربوط به پروژه و تصویر کلی آن ها) و آنچه که می خواهند تا به کمک این پروژه در حال حاضر و آینده به دست آوردند، آگاه باشید.
• شما فرایند کسب و کار را درک کرده و در صورت نیاز، آماده ارائه پیشنهاداتی برای بهبود و ساده سازی آن هستید. (برای مثال افزایش کارایی و درآمد، کاهش هزینه ها و ساعات کاری و…)
• شما جریان داده در شرکت مشتری را درک می کنید. در حالت ایده آل، شما به همه جزئیات واقف هستید: چه کسی با داده ها کار می کند، چه کسی تغییرات را ایجاد می کند، چه گزارش هایی لازم است، چه زمانی و چرا همه این اتفاقات می افتد و غیره.
• می توانید از اصطلاحات و دستور زبان هایی که مشتری استفاده می کند، استفاده کنید. در حالی که ممکن است شما در حوزه کاری مشتریان تخصصی نداشته باشید، مشتری شما قطعا یک متخصص است. از آن ها بخواهید تا هر آن چیزی که درباره حوزه کاریشان نمی دانید را به شما توضیح دهند. همچنین هنگام توضیح جزئیات فنی برای مشتری، از زبان و اصطلاحاتی که او می فهمد، استفاده کنید.
• شما می دانید که قرار است از چه فناوری هایی استفاده کنید. از موتور پایگاه داده گرفته تا زبان های برنامه نویسی و سایر ابزارهای دیگر. آن چیزی که شما تصمیم به استفاده از آن می گیرید، ارتباط نزدیکی با مشکلی دارد که قرار است آن را حل کنید. اما مهم است که اولویت مشتری و زیرساخت های فناوری اطلاعات فعلیشان را نیز لحاظ کنید.

در مرحله برنامه ریزی نیز برای جلوگیری از اشتباهات طراحی دیتابیس لازم است تا به سوالات زیر پاسخ دهید:

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

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

البته باید به خاطر داشته باشید که برنامه ریزی خوب، تنها مختص به مدل سازی داده ها نیست. برای جلوگیری از اشتباهات طراحی دیتابیس، تقریبا برای هر پروژه ای نیاز است تا برنامه ریزی را از ابتدا تا انتها داشته باشید. تنها زمانی که یا پروژه بسیار کوچکی دارید، یا وظایف و اهداف مشخص هستند و یا اینکه واقعا عجله دارید! می توانید از انجام برنامه ریزی چشم پوشی کنید. در غیر این صورت، برای جلوگیری از بروز اشتباهات طراحی دیتابیس، حتما برنامه ریزی داشته باشید.

2. ارتباط ناکافی با مشتریان و توسعه دهندگان

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

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

همه این موارد، می توانند باعث ایجاد تغییراتی در مدل دیتابیس شما شوند. اکثر این مدل ها نیاز دارند تا جداولی به آن ها اضافه شود. اما برخی از اوقات شما باید جداولی را حذف کرده و یا آن ها را تغییر دهید. برای این که از بروز چنین اشتباهات در طراحی دیتابیس جلوگیری کنید، لازم است تا اقدامات زیر را انجام دهید:

• با توسعه دهندگان و مشتریان صحبت کرده و از پرسیدن سوالات مهم تجاری نترسید. وقتی که فکر می کنید آماده شروع هستید، از خود بپرسید آیا وضعیت X در پایگاه داده ما پوشش داده شده است؟ مشتری در حال حاضر به روش Y این کار را انجام می دهد. آیا باید انتظار تغییر در آینده نزدیک را داشته باشیم؟ هنگامی که مطمئن شدیم مدل ما توانایی ذخیره هر آنچه را که نیاز داریم به روش صحیح دارد، می توانیم کدنویسی را شروع کنیم.
• اگر با تغییر عمده ای در طراحی خود مواجه هستید و قبلاً کدهای زیادی نوشته شده است، نباید برای انجام این تغییرات، سریعا تصمیم گیری کنید. اگر بدون توجه به شرایط فعلی، این تغییرات عمده را اعمال کنیم، ممکن است باعث بروز مشکلاتی شویم. یک تغییر سریع شاید در زمان ما صرفه جویی کند و احتمالاً برای مدتی خوب کار کند، اما می تواند بعداً به یک کابوس واقعی تبدیل شود.
• اگر فکر می‌کنید چیزی در حال حاضر مشکلی ندارد، اما ممکن است بعداً مشکل‌ساز شود، آن را نادیده نگیرید. آن بخش را تجزیه و تحلیل کرده و تغییراتی را در صورتی که کیفیت و عملکرد سیستم را بهبود بخشد، اعمال کنید. ممکن است این کار مدتی هزینه داشته باشد، اما در نهایت شما می توانید محصول بهتری ارائه کنید.

از این رو برای جلوگیری از چنین اشتباهات طراحی دیتابیس، در طول پروژه با مشتری و توسعه دهندگان خود در ارتباط باشید. همیشه بررسی کنید و ببینید که آیا از آخرین بحثی که با مشتریان و توسعه دهندگان داشته اید، چیزی تغییر کرده است یا خیر.

3. اسناد ضعیف و یا مفقود

برای بسیاری از طراحان دیتابیس، مستندات در آخرین بخش پروژه قرار خواهند گرفت. در صورتی که بتوانید پروژه را به خوبی سازماندهی کنید، احتمالا در پایان نیاز کمتری به ثبت موارد خواهید داشت. اما همیشه این طور نیست! طراحان دیتابیس، معمولا نوشتن مستندات را به آخر پروژه موکول می کنند. اما اگر برخی مستندات به درستی نوشته نشوند، ممکن است هزینه های چنین اشتباهات طراحی دیتابیس سنگین تر از آن چیزی که فکرش را می کنید، باشد.

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

حال که با برخی از مهمترین اشتباهات غیرفنی در زمان طراحی دیتابیس آشنا شدید، زمان آن رسیده است تا اشتباهات فنی را هم به شما معرفی کنیم.

4. عدم استفاده از قرارداد نامگذاری

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

• اسامی جدول مفرد هستند یا جمع؟
• آیا جداول را با استفاده از نام ها گروه بندی می کنید؟
• آیا از حروف بزرگ و کوچک استفاده می کنید یا فقط حروف کوچک؟
• از چه نامی برای ستون های ID استفاده خواهید کرد؟
• چگونه کلیدهای خارجی را نام گذاری می کنید؟

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

5. مسائل نرمال سازی

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

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

6. با استفاده از مدل Entity-Attribute-Value (EAV)

EAV مخفف entity-attribute-value است. این ساختار می تواند برای ذخیره داده های اضافی در مورد هر چیزی در مدل ما استفاده شود. بیایید به یک مثال نگاهی بیندازیم.

فرض کنید که می خواهیم برخی از ویژگی های اضافی را برای مشتری ذخیره کنیم. جدول “مشتری” موجودیت ما، جدول “ویژگی” مشخصاً ویژگی ما و جدول “ویژگی_مقدار” حاوی مقدار آن ویژگی برای آن مشتری است. ابتدا یک فرهنگ لغت با فهرستی از تمام ویژگی های ممکن که می توانیم به یک مشتری اختصاص دهیم، اضافه می کنیم. این جدول “ویژگی” است. می تواند حاوی ویژگی هایی مانند «ارزش مشتری»، «جزئیات تماس»، «اطلاعات اضافی» و غیره باشد. جدول «ویژگی_مشتری» حاوی فهرستی از همه ویژگی‌ها، با مقادیر، برای هر مشتری است. برای هر مشتری، ما فقط برای ویژگی هایی که دارند، سوابق خواهیم داشت و «ویژگی_مقدار» را برای آن ویژگی ذخیره می کنیم.

این حالت به ما اجازه می دهد تا ویژگی های جدید را اضافه کنیم. با این وجود در حالی که مدل، داده های مورد نیاز ما را ذخیره می کند، اما کار با چنین داده هایی سخت و پیچیده است. به صورت خلاصه یکی از اشتباهات طراحی دیتابیس، استفاده از ساختار EV است. تنها زمانی از این ساختار استفاده کنید که مطمئن هستید به آن نیاز دارید.

7. استفاده از GUID/UUID به عنوان کلید اصلی

GUID (شناسه منحصر به فرد جهانی) یک عدد 128 بیتی است که بر اساس قوانین تعریف شده در RFC 4122 تولید شده است. مزیت اصلی GUID منحصر به فرد بودن آن است. احتمال اینکه شما به دو GUID یکسان دست پیدا کنید، واقعا بعید است. بنابراین، GUID ها کاندیدای عالی برای ستون کلید اصلی به نظر می رسند. اما اینطور نیست!

یک قانون کلی برای کلیدهای اولیه این است که ما از یک ستون عدد صحیح با خاصیت افزایش خودکار روی “yes” استفاده می کنیم. این کار داده ها را به ترتیب به کلید اصلی اضافه می کند و عملکرد بهینه را ارائه می دهد. بدون کلید ترتیبی یا مهر زمانی، هیچ راهی برای دانستن اینکه کدام داده ابتدا وارد شده است، وجود ندارد. این مشکل همچنین زمانی ایجاد می شود که از مقادیر منحصر به فرد دنیای واقعی (مانند شناسه مالیات بر ارزش افزوده) استفاده می کنیم. در حالی که آنها مقادیر UNIQUE را دارند، کلیدهای اولیه خوبی نمی سازند. در عوض از آنها به عنوان کلیدهای جایگزین استفاده کنید.

8. نمایه سازی ناکافی

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

9. داده های اضافی

معمولاً در هر مدلی برای طراحی پایگاه داده، باید از داده های اضافی اجتناب شود. این کار نه تنها فضای دیسک را اشغال می کند، بلکه احتمال مشکلات یکپارچگی داده ها را نیز تا حد زیادی افزایش می دهد. اگر چیزی باید اضافه شود، لازم است مراقب باشید که داده‌های اصلی و «کپی» همیشه در حالت‌های ثابت باشند. در واقع، شرایطی وجود دارد که استفاده از داده‌های اضافی می تواند مطلوب باشد. با این وجود برای جلوگیری از اشتباهات طراحی دیتابیس، لازم است تا از داده های اضافی استفاده نکنیم؛ چرا که:

• ذخیره سازی یک داده بیش از یک بار در پایگاه داده می تواند بر یکپارچگی داده ها تأثیر بگذارد. اگر نام مشتری را در دو مکان مختلف ذخیره می کنید، باید هر تغییری را (درج/به‌روزرسانی/حذف) در هر دو مکان به صورت همزمان انجام دهید.
• در حالی که می توانیم تعدادی اعداد جمع‌آوری شده را در پایگاه داده عملیاتی خود ذخیره کنیم، باید این کار را فقط در زمانی که واقعاً نیاز داریم انجام دهیم. یک پایگاه داده عملیاتی فضای مناسبی برای ذخیره داده های گزارش دهی نیست و ترکیب این دو به طور کلی عمل بدی است. هر کسی که گزارش تولید می کند باید از منابع مشابه کاربرانی که روی وظایف عملیاتی کار می کنند استفاده کند. پرس و جوهای گزارش معمولاً پیچیده تر هستند و می توانند بر عملکرد تأثیر بگذارند. بنابراین، شما باید پایگاه داده عملیاتی خود را از پایگاه داده گزارش خود جدا کنید.