چه چیزی بهعنوان یک موجودیت شمرده میشود
یک Entity (موجودیت) یک شیء، مفهوم، یا رویداد دنیای واقعی متمایز است که یک دیتابیس نیاز دارد اطلاعات دربارهاش را ذخیره کند — یک مشتری، یک محصول، یک سفارش، یا یک قرار ملاقات همگی موجودیتهای معمول هستند. شناسایی موجودیتها اولین گام مرحله طراحی مفهومی که پیشتر در این مجموعه بحث شد است، و نیازمند پرسیدن یک پرسش ساده اما مهم است: "چیزهایی" که این اپلیکیشن نیاز دارد ردیابی کند چه هستند؟
مثال موجودیتها برای یک فروشگاه کتاب آنلاین:
- کتاب
- نویسنده
- مشتری
- سفارش
- ناشرهر موجودیت در نهایت یک جدول میشود، اما در این مرحله اولیه هدف صرفاً شناسایی مفاهیم متمایز درگیر است، بدون نگرانی هنوز درباره ستونها، انواع داده، یا نحو SQL.
ویژگیها: توصیف جزئیات یک موجودیت
یک Attribute (ویژگی) یک قطعه خاص از اطلاعات است که یک موجودیت را توصیف میکند. یک موجودیت کتاب، برای مثال، ممکن است ویژگیهایی مانند عنوان، سال انتشار، و قیمت داشته باشد — هرکدام از اینها در نهایت یک ستون در جدول متناظر میشود.
موجودیت کتاب و ویژگیهایش:
- عنوان
- شابک
- سال انتشار
- قیمت
- تعداد صفحهیک اشتباه رایج در این مرحله شاملکردن ویژگیهای زیاد یا کم است: حذف یک ویژگی که اپلیکیشن واقعاً نیاز خواهد داشت یک تغییر اسکیمای دشوار بعداً اجبار میکند، که پیشتر در این مجموعه درباره هزینه تصحیحات دیرهنگام طراحی بحث شد، در حالی که شاملکردن ویژگیهای نامرتبط طراحی را شلوغ میکند و میتواند سردرگمی واقعی درباره اینکه هر قطعه داده واقعاً چه چیزی را نمایش میدهد ایجاد کند.
انواع ویژگیها
ویژگیها همه یک نوع چیز نیستند، و تشخیص این تمایزات کمک میکند مسائل طراحی زود شناسایی شوند.
ویژگیهای ساده در مقابل ترکیبی
یک Simple Attribute (ویژگی ساده) نمیتواند بهطور معنادار بیشتر تجزیه شود، مانند تعداد صفحه. یک Composite Attribute (ویژگی ترکیبی) از قطعات کوچکتر و معنادار تشکیل شده، مانند یک آدرس، که بهطور طبیعی به خیابان، شهر، و کد پستی تجزیه میشود.
مثال ویژگی ترکیبی:
آدرس → خیابان، شهر، استان، کد پستی
اینکه اینها را بهعنوان یک فیلد ترکیبشده یا
چند ستون جداگانه ذخیره کنیم به این بستگی دارد
که آیا اپلیکیشن نیاز دارد بر اساس قطعات منفرد
پرسوجو یا مرتبسازی کند — اگر جستجوهای مبتنیبر-شهر
مورد نیاز باشند، آدرس باید به ستونهای جداگانه تقسیم شودویژگیهای تکمقداری در مقابل چندمقداری
یک Single-Valued Attribute (ویژگی تکمقداری) دقیقاً یک مقدار بهازای هر موجودیت نگه میدارد، مانند شابک یک کتاب. یک Multi-Valued Attribute (ویژگی چندمقداری) میتواند چند مقدار برای یک موجودیت واحد نگه دارد، مانند یک کتاب که بالقوه چند نویسنده دارد. ویژگیهای چندمقداری نمیتوانند مستقیماً بهعنوان یک ستون واحد در یک جدول رابطهای بدون نقض اصول طراحی خوب ذخیره شوند، و در عوض نیازمند یک جدول مرتبط جداگانه هستند — تکنیکی که در مقاله روابط بعداً در این مجموعه بهطور عمیق بررسی میشود.
ویژگیهای ذخیرهشده در مقابل مشتقشده
یک Stored Attribute (ویژگی ذخیرهشده) یک مقدار نگه میدارد که باید صراحتاً ذخیره شود، مانند تاریخ تولد. یک Derived Attribute (ویژگی مشتقشده) میتواند از سایر ویژگیهای ذخیرهشده هروقت نیاز باشد محاسبه شود، مانند سن، که همیشه میتواند از یک تاریخ تولد ذخیرهشده محاسبه شود.
مثال ویژگی مشتقشده:
سن = تاریخ_فعلی - تاریخ_تولد
ذخیره "سن" مستقیماً بهعنوان یک ستون
داده تکراریای ایجاد میکرد که در لحظه گذشتن زمان
بیاعتبار میشود، چون باید بهصورت دستی برای درستماندن
بهروزرسانی شود — ذخیره فقط تاریخ_تولد و محاسبه سن
بهصورت درخواستی این ریسک ناسازگاری را کاملاً اجتناب میکندبهعنوان یک اصل طراحی کلی، ویژگیهای مشتقشده معمولاً نباید مستقیماً ذخیره شوند، چون این کار یک مقدار تکراری معرفی میکند که میتواند بیسروصدا با دادهای که از آن مشتق شده ناسازگار شود، مگر اینکه نیازمندیهای کارایی بهطور خاص این مصالحه را توجیه کنند.
انتخاب یک کلید: شناسایی یکتای هر نمونه موجودیت
هر موجودیت نیازمند راهی برای تشخیص یکتای یک نمونه از دیگری است — این به کلید اصلی جدول، که پیشتر در این مجموعه معرفی شد، تبدیل میشود. انتخاب یک کلید مناسب یکی از تصمیمات پرتبعاتتر در طراحی موجودیت است.
کلیدهای طبیعی در مقابل کلیدهای مصنوعی
یک Natural Key (کلید طبیعی) ویژگیای است که از قبل در داده دنیای واقعی وجود دارد و اتفاقاً یکتاست، مانند یک شابک برای یک کتاب یا یک شماره شناسایی ملی برای یک فرد. یک Surrogate Key (کلید مصنوعی) یک شناسه مصنوعی است، معمولاً یک عدد خودافزاینده، ساختهشده صرفاً برای هدف شناسایی یکتای ردیفها، بدون هیچ معنای دنیای واقعی خودش.
مثال کلید طبیعی:
شابک بهعنوان کلید اصلی برای یک جدول کتابها
مثال کلید مصنوعی:
book_id (یک عدد صحیح خودافزاینده)
بهعنوان کلید اصلی، با شابک ذخیرهشده بهعنوان
یک ویژگی جداگانه و غیرکلیدیکلیدهای مصنوعی معمولاً در عمل ترجیح داده میشوند، حتی وقتی یک کلید طبیعی وجود دارد، چون کلیدهای طبیعی گاهی میتوانند تغییر کنند (شناسه ملی یک فرد ممکن است دوباره صادر شود، یا کد یک محصول ممکن است بازبینی شود)، و هر تغییری در یک مقدار کلید اصلی از میان هر کلید خارجی که به آن در جای دیگری در دیتابیس ارجاع میدهد موج میزند — یک کلید مصنوعی، که هیچ معنای خارجیای ندارد، هرگز نیاز به تغییر برای دلایل کسبوکاری ندارد.
چرا شناسایی دقیق موجودیت و ویژگی اهمیت دارد
موجودیتها و ویژگیهای شناساییشده در طول این مرحله مفهومی اولیه مستقیماً به جداول و ستونهای اسکیمای دیتابیس نهایی تبدیل میشوند. یک اشتباه در اینجا — ادغام دو موجودیت متمایز در یکی، ازدستدادن یک ویژگی مهم، یا انتخاب یک کلید ضعیف — تمایل دارد در سراسر هر تصمیم طراحی بعدی آبشاری شود، که این کار شناسایی دقیق و عمدی را به یکی از پرتأثیرترین گامها در کل فرآیند طراحی دیتابیس که در سراسر این مجموعه بحث شد تبدیل میکند.