سئوالاتی درباره sql

[the_king]

سلامی مجدد
خیلی ممنون استاد .

استاد ، در محیط Sql Server Management Studio (SSMS) ، میخوام حالت گرافیکی ای که برای تولید کدهای query وجود داره ، استفاده کنم .
یعنی محیطی که در لینک زیر هست را میخوام (diagrame pane و ... که در این لینک هستن) :

Graphical Query Designer User Interface - SQL Server Reporting Services (SSRS)

Learn about the graphical query designer user interface so you can retrieve data from a relational database for a report dataset in Report Designer.

learn.microsoft.com

و

Diagram Pane - Visual Database Tools

Diagram Pane (Visual Database Tools)

learn.microsoft.com

که اگه اشتباه نکنم ، میگه برای این کار ، باید ابزار Visual Database Tools را نصب کنیم .
اما این ابزار ، انگار فقط برای Visual Studio موجود هست :

Download SQL Server Data Tools (SSDT) - SQL Server Data Tools (SSDT)

Learn about SQL Server Data Tools (SSDT). See how to install this database development tool set with Visual Studio 2019 and Visual Studio 2017.

learn.microsoft.com

منتها من برای ویژال استودیو نمیخوام .
فقط برای محیط SSMS یا کلا برای محیط نرم افزار sql server میخوام .
همچین چیزی برای این محیط ، وجود داره؟
اگه آره ، از کجا باید دانلود کنم؟

تشکر استاد .

در Object Explorer یکی از Table های Database مورد نظرتون رو انتخاب کنید، رویش راست کلید کنید و فرضا با گزینه Select Top 1000 Rows برایش یک Query بسازید. حالا بالا در منوی Query با گزینه Design Query in Editor وارد اون پنجره گرافیکی Query Designer می شوید.

 

[SajjadKhati]

سلامی مجدد استاد .
خیلی ممنون از جواب تون .

به غیر از چیزی که گفتید ، متوجه شدم توی view هم میشه این کار را انگار انجام داد .

استاد ، مشکل حدودی ام با sql ، حفظ کردن دستوراتش هست (برای من که مبتدی ام) .
البته میدونم که به راحتی دستوراتش را میتونم در اینترنت جستجو کنم (ولی در قیاس با کسانی که بصورت حفظی و سریع دستوراتش را مینویسن ، منظورم هست) .

فرضا visual studio که intellisense داره و فرضا وقتی دستور for را مینویسیم و خودش پیشنهاد میده که tab را دو بار بزنیم تا دستوراتش را خودش بیاره و بعد از اون ما میتونیم دستوراتش را ویرایش کنیم ، در SSMS ، شبیه همچین چیزی وجود نداره؟ (اگه نداره ، چرا؟)
یعنی فرضا وقتی در کوئری اش بنویسیم select ، خودش دستورش را بیاره و ما ویرایش اش کنیم .
همچین چیزی (شبیه intellisense اما در SSMS) که خیلی نیازه . نمیدونم چرا در visual studio نیازش را به درستی تشخیص دادن اما در SSMS و کلا محیط کوئری نویسی ، این نیاز را برای مبتدیان (یا برای تسریع در روند کد نویسی) حس نمیکنن !

تشکر استاد .

 

[the_king]

سلامی مجدد استاد .
خیلی ممنون از جواب تون .

به غیر از چیزی که گفتید ، متوجه شدم توی view هم میشه این کار را انگار انجام داد .

استاد ، مشکل حدودی ام با sql ، حفظ کردن دستوراتش هست (برای من که مبتدی ام) .
البته میدونم که به راحتی دستوراتش را میتونم در اینترنت جستجو کنم (ولی در قیاس با کسانی که بصورت حفظی و سریع دستوراتش را مینویسن ، منظورم هست) .

فرضا visual studio که intellisense داره و فرضا وقتی دستور for را مینویسیم و خودش پیشنهاد میده که tab را دو بار بزنیم تا دستوراتش را خودش بیاره و بعد از اون ما میتونیم دستوراتش را ویرایش کنیم ، در SSMS ، شبیه همچین چیزی وجود نداره؟ (اگه نداره ، چرا؟)
یعنی فرضا وقتی در کوئری اش بنویسیم select ، خودش دستورش را بیاره و ما ویرایش اش کنیم .
همچین چیزی (شبیه intellisense اما در SSMS) که خیلی نیازه . نمیدونم چرا در visual studio نیازش را به درستی تشخیص دادن اما در SSMS و کلا محیط کوئری نویسی ، این نیاز را برای مبتدیان (یا برای تسریع در روند کد نویسی) حس نمیکنن !

تشکر استاد .

دو تا مساله هست، اول اینکه SSMS برای مبتدی های SQL نویسی یا آموزش SQL نویسی طراحی نشده، برای متصدی مدیریت پایگاه داده است که اگر نیازی به SQL نویسی هم داشته باشه اونقدر به اینکار تسلط داره که نیازی به پیشنهادات ویرایشگر نداره.
مساله دوم اینه که قالب دستورات SQL به مراتب مولفه های بیشتری داره که با snippet های ساده #C قابل مقایسه نیست.

Ultimate SQL Cheat Sheet (Download PDF) 2024 : Queries, Commands, Etc.

A detailed article about SQL Cheat Sheet which includes keywords, data types, operators, functions, indexes, keys, and lots more. Download it in PDF format.

kanakinfosystems.com

می توانید پلاگین SQL Prompt (جزئی از مجموعه Red-Gate SQL Toolbelt) رو به SSMS (و Visual Studio) اضافه کنید تا intellisense اش اضافه بشه.

 

[SajjadKhati]

دو تا مساله هست، اول اینکه SSMS برای مبتدی های SQL نویسی یا آموزش SQL نویسی طراحی نشده، برای متصدی مدیریت پایگاه داده است که اگر نیازی به SQL نویسی هم داشته باشه اونقدر به اینکار تسلط داره که نیازی به پیشنهادات ویرایشگر نداره.
مساله دوم اینه که قالب دستورات SQL به مراتب مولفه های بیشتری داره که با snippet های ساده #C قابل مقایسه نیست.

Ultimate SQL Cheat Sheet (Download PDF) 2024 : Queries, Commands, Etc.

A detailed article about SQL Cheat Sheet which includes keywords, data types, operators, functions, indexes, keys, and lots more. Download it in PDF format.

kanakinfosystems.com

می توانید پلاگین SQL Prompt (جزئی از مجموعه Red-Gate SQL Toolbelt) رو به SSMS (و Visual Studio) اضافه کنید تا intellisense اش اضافه بشه.

خیلی ممنون استاد .
پلاگین خوبی بود (حداقل ، برای من تاثیر گذار هه) .
فقط نمیدونم چرا در بعضی از دستورات مثل Insert که مینویسیم و دکمه ی Tab را میزنیم ، کامل دستوراتش را میاره (یعنی تا عبارت Value را هم در ادامه اش میاره که میتونیم ویرایش کنیم که من هم همین جوری مد نظرم هست) اما در بعضی از دستورات دیگه مثل Select و اینها ، اون طور نیست و عبارات را تا آخر نمیاره (اگه میاورد ، خیلی بهتر میشد) (هر چند در این حالت ، کلمه ی بعدی را توی لیست Intellisense اش میاره و همین اش هم کمک کننده هست) .
قویتر از این پلاگین هم هست؟

بعد اینکه این ssms ، وقتی توش میریم و هیچ دیتابیس ای هم قبلا خودمون ایجاد نکردیم ، چرا این قدر دیتابیس های از قبل ایجاد شده داره؟

بعد اینکه نام ستون را نمیتونیم بین شون فضای خالی بدیم؟
فرضا نام "First Name" را نمیتونیم به عنوان نام فیلدمون تعیین کنیم؟
اگه میتونیم ، در دستور select اش چجوری باید نام فیلد را بنویسیم که ارور نگیره؟

بعد هم من نام "Name" را به عنوان نام فیلدم نوشتم ، هر چند موقع دستور select ، در پنل error ، اشکال و ارور گرفت اما دستورش با موفقیت اجرا شد . دلیلش چیه؟!

--------------

استاد ، میگم در تاپیک های دیگه مثل اون تاپیک "مباحث wpf" یا "گفتگوهایی در باب سی شارپ" ، وقتی شما یا کس دیگه ای پست جدیدی در اون تاپیک میداد ، بهم ایمیل میومد اما در این تاپیک ، با اونکه در این تاپیک هم مشترک هستم ، ولی با ارسال پست جدید ، بهم ایمیل نمیاد . چرا و چی کار باید کنم تا بیاد؟

تشکر استاد .

 

[the_king]

خیلی ممنون استاد .
پلاگین خوبی بود (حداقل ، برای من تاثیر گذار هه) .
فقط نمیدونم چرا در بعضی از دستورات مثل Insert که مینویسیم و دکمه ی Tab را میزنیم ، کامل دستوراتش را میاره (یعنی تا عبارت Value را هم در ادامه اش میاره که میتونیم ویرایش کنیم که من هم همین جوری مد نظرم هست) اما در بعضی از دستورات دیگه مثل Select و اینها ، اون طور نیست و عبارات را تا آخر نمیاره (اگه میاورد ، خیلی بهتر میشد) (هر چند در این حالت ، کلمه ی بعدی را توی لیست Intellisense اش میاره و همین اش هم کمک کننده هست) .
قویتر از این پلاگین هم هست؟

نمیدونم. Query Builder ها خیلی زیاد هستند و اغلب شون هم واسط کاربری ویرایشگر شون از این ساده تر ئه و بجایش تمرکز شون روی طراحی ویژوال Query ئه که نیازی به چیزی مثل Intellisense نداره.

بعد اینکه این ssms ، وقتی توش میریم و هیچ دیتابیس ای هم قبلا خودمون ایجاد نکردیم ، چرا این قدر دیتابیس های از قبل ایجاد شده داره؟

پایگاه داده های سیستمی SQL Server که باید باشند، پایگاه داده سایر برنامه ها و پایگاه داده های نمونه مثل Northwind.

بعد اینکه نام ستون را نمیتونیم بین شون فضای خالی بدیم؟
فرضا نام "First Name" را نمیتونیم به عنوان نام فیلدمون تعیین کنیم؟

قواعد SQL رو باید رعایت کنید، space جدا کننده قواعد ئه، اگر بنویسید First Name اون First یک عبارت ئه و Name رو عبارت بعدی تفسیر میکنه.
پس باید First Name بصورت "First Name" یا [First Name] مشخص بشه.

CREATE TABLE [TestTable]([First Name] [NCHAR](100) NULL)

اگه میتونیم ، در دستور select اش چجوری باید نام فیلد را بنویسیم که ارور نگیره؟

بعد هم من نام "Name" را به عنوان نام فیلدم نوشتم ، هر چند موقع دستور select ، در پنل error ، اشکال و ارور گرفت اما دستورش با موفقیت اجرا شد . دلیلش چیه؟!

احتمالا نسخه ای که نصب کرده اید با نسخه SSMS سازگار نیست یا باگ داره یا چیزی شبیه به این.

استاد ، میگم در تاپیک های دیگه مثل اون تاپیک "مباحث wpf" یا "گفتگوهایی در باب سی شارپ" ، وقتی شما یا کس دیگه ای پست جدیدی در اون تاپیک میداد ، بهم ایمیل میومد اما در این تاپیک ، با اونکه در این تاپیک هم مشترک هستم ، ولی با ارسال پست جدید ، بهم ایمیل نمیاد . چرا و چی کار باید کنم تا بیاد؟

تنها کاری که میتونید بکنید اینه که چک کنید که ایمیل ها تحت عنوان اسپم دریافت نشده باشه.

 

[SajjadKhati]

سلامی مجدد استاد .
خیلی ممنون از جواب پست قبلی تون .
ایمیلی توی بخش اسپم هم نمیاد .

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

هر چند در پایگاه داده ، مبتدی هستم . اما نمیدونم این ها دیگه چه سئوالاتی هستن .
هر چند مدت در میون شاید به سئوالات این pdf اشاره کنم (همه را یه دفعه نمیتونم یاد بگیرم) . نمیدونم سئوال شون سخت هه یا من خیلی بیش از حد مبتدی هستم .

---------

فرضا ، سئوال 1 اش اصلا یعنی چی و درباره ی چی صحبت میکنه؟
رابطه و وابستگی تابعی اصلا یعنی چی؟
برای اطلاعات بیشتر در این باره ، باید چه چیزها و منابعی را بخونم؟

من بعضی از آموزش های پایگاه داده را دیدم . اطلاعات نسبی و مبتدی ای از ساخت یک و یا چندین جدول و فیلد ، (تقریبا join کردن شون) ، ساخت view و stored procedure و index و trigger و از این چیزها و همچنین ado.net دارم .
توی هیچ کدوم از این مطالب ، هیچ مطلبی درباره ی سئوال بالا (رابطه و وابستگی و اینها) اصلا هیچ صحبتی نکردن .

یا فرضا در سئوال 5 یا 9 و 18 اش ، عملگر و کلا موضوع جبر رابطه ای که نمیدونم چیه .

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

یا نمودار ER در سئوال شماره 13 اصلا نمیدونم چیه .
یا سئوال شماره 14 و 15 درباره BCNF و اینها .
و همچنین 19 و 20 .

----------------

استاد ، الان این سئوالاتی که اشاره کردم ، برای اینکه اصلا متوجه بشم اینها داره درباره ی چی صحبت میکنه ، باید چه منابعی را بخونم؟
اصلا این سئوالاتی را که اشاره کردم که اصلا نمیدونم درباره ی چی صحبت میکنه ، یعنی مبانی پایگاه داده را نمیدونم؟
فرضا باید کتابی با عنوان مبانی پایگاه داده را برای خوندن جستجو کنم؟

الان فرضا یکی از مبانی برنامه نویسی ، عملگرها و بیت ها و اعداد دودویی و کلا ریاضی گسسته هست ، پایگاه داده هم برای خودش باز ، مبانی مجزایی داره؟
اگه آره ، مباحث اش چه چیزهایی هستن؟
و منابع (کلی) اش چه چیزهایی برای یادگیری هستن؟

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

تشکر استاد .

 

[the_king]

سلامی مجدد استاد .
خیلی ممنون از جواب پست قبلی تون .
ایمیلی توی بخش اسپم هم نمیاد .

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

هر چند در پایگاه داده ، مبتدی هستم . اما نمیدونم این ها دیگه چه سئوالاتی هستن .
هر چند مدت در میون شاید به سئوالات این pdf اشاره کنم (همه را یه دفعه نمیتونم یاد بگیرم) . نمیدونم سئوال شون سخت هه یا من خیلی بیش از حد مبتدی هستم .

---------

فرضا ، سئوال 1 اش اصلا یعنی چی و درباره ی چی صحبت میکنه؟

در مورد رابطه و وابستگی تابعی، در مورد اینکه اگر بخواهید برای فلان ستون ها (اونهایی که در رابطه R اومده) که قراره در یک جدول کنار هم باشند یک کلید مرکب (ترکیب یک یا چند ستون) در نظر بگیرید، چه ستونهایی باید در کلید باشند و کدومها اضافی هستند و نباید در کلید باشند؟
همه ستون ها در کلید باشند؟ نه، چون فرضا به شما میگه اگر A و B رو در کلید داشته باشید، C رو بهتون میده (یعنی تابعی هست که A و B ورودی هاش هستند و C خروجی اش). بنابر این اگر A و B در کلید رابطه R باشند، دیگه وجود C در این کلید بی مورد ئه چون میشه بدستش آورد، اما فرضا اگر هیچ تابعی سراغ ندارید که ورودی هاش رو در کلید مرکب R تمام و کمال داشته باشید (تابعی که ورودی ها رو بدهید و بهتون A رو بده)، پس حتما باید A در کلید مرکب تون باشه، یعنی نمی توانید کلید مرکب ای رو برای R انتخاب کنید که نه A داخل کلید اش باشه و نه با اعضاء کلید اش بشه A رو بدست آورد.

رابطه و وابستگی تابعی اصلا یعنی چی؟
برای اطلاعات بیشتر در این باره ، باید چه چیزها و منابعی را بخونم؟

وابستگی تابعی احتمالا در همه کتاب های پایگاه داده معرفی شده در دانشگاه ها هست، کتاب فارسی هم زیاد دارند، Pdf هاشون هم هست.

http://chap.sch.ir/sites/default/files/lbooks/91-92/412/C612-13-abed.pdf

من بعضی از آموزش های پایگاه داده را دیدم . اطلاعات نسبی و مبتدی ای از ساخت یک و یا چندین جدول و فیلد ، (تقریبا join کردن شون) ، ساخت view و stored procedure و index و trigger و از این چیزها و همچنین ado.net دارم .
توی هیچ کدوم از این مطالب ، هیچ مطلبی درباره ی سئوال بالا (رابطه و وابستگی و اینها) اصلا هیچ صحبتی نکردن .

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

یا فرضا در سئوال 5 یا 9 و 18 اش ، عملگر و کلا موضوع جبر رابطه ای که نمیدونم چیه .

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

یا نمودار ER در سئوال شماره 13 اصلا نمیدونم چیه .
یا سئوال شماره 14 و 15 درباره BCNF و اینها .
و همچنین 19 و 20 .

اینها مربوط به اصول طراحی پایگاه داده است. شما یک مدل رو به دو نفر - یکنفر که اصول طراحی پایگاه داده رو میدونه و یکنفر که نمیدونه - نشون می دهید (مدل مثلا یک مدرسه است که قراره برای برایش پایگاه داده طراحی بشه، اطلاعات معلم و کلاس و شاگرد و درس و نمره و ...) هر کدوم از این دو نفر بر اساس این مدل و فعالیت هایی که داخلش هست و اجزاء اش و ارتباطی که بین اجزاء اش هست و ... پایگاه داده ای طراحی می کنند.
کاری به کد نویسی SQL یا #C اش نداریم، مرحله پیاده سازی اش نیست، قبل از اونه، صحبت از طراحی پایگاه داده است، یعنی اینکه چه جداولی باید باشه، چه ستون هایی باشه، چه کوئری هایی باشه، بین جداول چه روابطی باشه، چه ستون هایی کلید باشند و ...
حالا این دو نفر پایگاه داده رو به یک شکل یکسان طراحی می کنند؟ طبعا نه، تعداد جداول شون، کلید هاشون، کوئری هاشون و ... با هم فرق می کنه.
این تفاوت ها باعث چی میشه؟ خیلی چیزها. اصول طراحی پایگاه داده ها تمرکز اش رو همون خیلی چیز ها است، روی اصولی که باید رعایت بشه.
این روابطی که به گوش تون نخورده مربوط به تحلیل همون مدل ئه، برای اینه که بفهمید در مدل چه خبر ئه تا بر اساسش پایگاه داده رو منطبق با اون روابط طراحی کنید.

استاد ، الان این سئوالاتی که اشاره کردم ، برای اینکه اصلا متوجه بشم اینها داره درباره ی چی صحبت میکنه ، باید چه منابعی را بخونم؟

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

اصلا این سئوالاتی را که اشاره کردم که اصلا نمیدونم درباره ی چی صحبت میکنه ، یعنی مبانی پایگاه داده را نمیدونم؟

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

فرضا باید کتابی با عنوان مبانی پایگاه داده را برای خوندن جستجو کنم؟

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

الان فرضا یکی از مبانی برنامه نویسی ، عملگرها و بیت ها و اعداد دودویی و کلا ریاضی گسسته هست ، پایگاه داده هم برای خودش باز ، مبانی مجزایی داره؟
اگه آره ، مباحث اش چه چیزهایی هستن؟
و منابع (کلی) اش چه چیزهایی برای یادگیری هستن؟

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

اگه آره ، مباحث اش چه چیزهایی هستن
و منابع (کلی) اش چه چیزهایی برای یادگیری هستن؟

خیلی چیزها، در مورد NoSQL و Big Data و (Graph Database (GDB جستجو کنید، یک دریای بیکران ئه. هر کدوم مبانی خودش رو داره. در مورد کاربرد هایی که پایگاه داده های کلاسیک پاسخگوی نیازمندی هاشون نیستند.

این مباحث در پایگاه داده به چه درد میخوره؟

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

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

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

 

[SajjadKhati]

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



استاد ، در یه آموزش ، طرف ، همچین جداولی کشید :



که Customers ، جدول مشتری و Recipt ، جدول سفارش و Food هم جدول غذا هست .
که در اون ها ، Customer_Id و Food_Id ای که در جدول Recipt قرار دارن ، کلید خارجی هستند .

فیلد Customer_Id که کلید خارجی برای Id ئه جدول Customers هست ، درسته .
اما Food_Id که باید غلط باشه .

به نظر من در جدول Food ، باید یه کلید خارجی فرضا بنام Recipt_Id تعریف میشد که به فیلد Id ئه جدول Recipt اشاره کنه . درست میگم؟
اینکه داخل جدول Recipt ، کلید خارجی ای باشه که به جدول Food اشاره کنه که غلط هست . درسته؟

===========

اینهایی که میگم ، درسته (با توجه به شکل بالا) :

با توجه به Entity Framework که یه رابط شی گرا ، برای مدل سازی و ارتباط برقرار کردن با ado.net هست (مخصوصا model first اش که مفاهیم شی گرایی توش بیشتر از database first هست) ، معادل جدول Customers در EF ، یه کلاسی بنام Customers هست که پروپرتی هایی با نام هایی که در اون جدول مشخص شدن ، داره .

جدول هایی که کلید خارجی دارن ، در EF ، کلاسی هستند که عضوی (فرضا پروپرتی ای) از کالکشن ای از این نوع را در کلاسی که کلید خارجی بهش اشاره میکنه ، دارن .
فرضا در EF ، در کلاس Customers ، عضوی از نوع کالکشن ای از Recipt وجود داره (چون در دیتابیس ، درون جدول Recipt ، کلید خارجی ای به جدول Customers داره) .

پس هر وقت ، یه کالکشن ای بخوایم در کلاس مربوط به EF (یا فرضا در کلاس سی شارپ خودمون) قرار بدیم (مثلا کالکشن را درون کلاس Customers قرار بدیم) ، باید به ازای اون کالکشن ، در دیتابیس ، یه جدول دیگه ای بسازیم که کلید خارجی ای داشته باشه (مثل جدول Recipt) که اون کلید خارجی اش ، به جدول مورد نظرش اشاره کنه .

چرا؟
چون وقتی کالکشن یا آرایه ای در یه کلاس میسازیم ، به ازای یه شی از اون کلاس (به ازای یه شی از کلاس Customers در EF) ، میتونیم بیش از یه مقدار برای اون کالکشن در نظر بگیریم (کالکشنِ ای از نوع Recipt که در کلاس Customers در EF وجود داره) . و این موضوع ، یعنی اینکه بتونیم به ازای یه سطر از یه فیلد ، بیش از یک مقدار به سطرِ فیلدِ دیگه در همون جدول بدیم ، در این صورت باید جدول جداگانه ی دیگه ای برای اون فیلد مورد نظرمون بسازیم (جدول Recipt) .

=======

حالا در جداول بالا ، هر مشتری (Customers) ، میتونه یک یا چند تا سفارش (Recipt) داشته باشه . پس تا اینجا درسته که جدول Recipt جدا بشه و کلید خارجی ای در جدول Recipt تعریف بشه که به جدول Customers اشاره کنه (کلید Customer_Id در جدول Recipt) .

و همچنین هر سفارش (Recipt) هم میتونه شامل یک ، یا چند غذا باشه (پس تا اینجا هم درسته که جدول Food ، جدای از جدول Recipt بشه) .

اما نکته اینجاست که غذا (Food) ، متعلق به (و عضوی از) سفارش (Recipt) هست .
پس داخل جدول Food ، باید کلید خارجی ای وجود میداشت که به جدول Recipt اشاره کنه .

اما در این جدولی که نشون داد ، درون جدول Recipt ، کلید خارجی ای وجود داره که به جدول Food اشاره میکنه . درست میگم دیگه؟
اگه درست میگم ، پس این آموزش دهنده اشتباه کرد دیگه؟
چون وقتی کلید خارجیِ Food_Id را درون جدول Recipt گذاشت ، یعنی جدول Recipt ، متعلق (و در EF ، عضوی از) Food هست . در صورتی که "سفارش" ، متعلق به "غذا" نیست . بلکه "غذا" ، متعلق به "سفارش" هست ، به این معنا که هر سفارش ، میتونه یک یا چند غذا را شامل بشه . اما غذا که نمیتونه سفارش را شامل بشه .
درست میگم؟

تشکر استاد .

 

[the_king]

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



استاد ، در یه آموزش ، طرف ، همچین جداولی کشید :

مشاهده پیوست 115689

که Customers ، جدول مشتری و Recipt ، جدول سفارش و Food هم جدول غذا هست .
که در اون ها ، Customer_Id و Food_Id ای که در جدول Recipt قرار دارن ، کلید خارجی هستند .

فیلد Customer_Id که کلید خارجی برای Id ئه جدول Customers هست ، درسته .
اما Food_Id که باید غلط باشه .

به نظر من در جدول Food ، باید یه کلید خارجی فرضا بنام Recipt_Id تعریف میشد که به فیلد Id ئه جدول Recipt اشاره کنه . درست میگم؟

نه. روابط در نظر نگیرید همین مشکل پیدا میشه دیگه. Food جدول تعریف غذا ها است، فرضا چلوکباب در اون یک رکورد داره. این تک رکورد چلوکباب باید با چندین رکورد سفارش در جدول Recipt در ارتباط باشه، نه فقط یک رکورد سفارش. شما اگر در جدول Food یک ستون Recipt_Id اضافه کنید اون رکورد چلوکباب رو به کدوم یکی از سفارش ها ربط می دهید؟ بقیه سفارش ها چی؟ یا میخواهید برای هر سفارش یکبار از نو تعریف چلوکباب و قیمت اش رو در رکورد جدیدی داخل Food بذارید؟ درست نیست.

اینکه داخل جدول Recipt ، کلید خارجی ای باشه که به جدول Food اشاره کنه که غلط هست . درسته؟

نه.

با توجه به Entity Framework که یه رابط شی گرا ، برای مدل سازی و ارتباط برقرار کردن با ado.net هست (مخصوصا model first اش که مفاهیم شی گرایی توش بیشتر از database first هست) ، معادل جدول Customers در EF ، یه کلاسی بنام Customers هست که پروپرتی هایی با نام هایی که در اون جدول مشخص شدن ، داره .

بله.

جدول هایی که کلید خارجی دارن ، در EF ، کلاسی هستند که عضوی (فرضا پروپرتی ای) از کالکشن ای از این نوع را در کلاسی که کلید خارجی بهش اشاره میکنه ، دارن .

بله.

فرضا در EF ، در کلاس Customers ، عضوی از نوع کالکشن ای از Recipt وجود داره (چون در دیتابیس ، درون جدول Recipt ، کلید خارجی ای به جدول Customers داره) .

بله، ولی ممکنه مجموعه باشه، ICollection باشه، روابط الزاما یک به یک نیست، ممکنه یک به چند یا چند به یک یا چند به چند باشه. فرضا هر مشتری ممکنه چند تا سفارش داشته باشه. البته این جدول Recipt اساسا برای سفارشی تک موردی طراحی شده، فرضا در یک سفارش چلوکباب و در سفارش بعدی نوشابه، نه هر دو با هم.

حالا در جداول بالا ، هر مشتری (Customers) ، میتونه یک یا چند تا سفارش (Recipt) داشته باشه . پس تا اینجا درسته که جدول Recipt جدا بشه و کلید خارجی ای در جدول Recipt تعریف بشه که به جدول Customers اشاره کنه (کلید Customer_Id در جدول Recipt) .

و همچنین هر سفارش (Recipt) هم میتونه شامل یک ، یا چند غذا باشه (پس تا اینجا هم درسته که جدول Food ، جدای از جدول Recipt بشه) .

اما نکته اینجاست که غذا (Food) ، متعلق به (و عضوی از) سفارش (Recipt) هست .

نه. غذا متعلق به هیچ سفارش خاصی نیست، عمومی ئه، سفارش های متعددی به غذای واحدی اشاره می کنند. یک غذای چلوکباب با صد ها سفارش چلوکباب در ارتباط ئه. ارتباط شون به واسطه کد غذا است، نه کد سفارش.

پس داخل جدول Food ، باید کلید خارجی ای وجود میداشت که به جدول Recipt اشاره کنه .

خیر.

اما در این جدولی که نشون داد ، درون جدول Recipt ، کلید خارجی ای وجود داره که به جدول Food اشاره میکنه . درست میگم دیگه؟

خیر.

اگه درست میگم ، پس این آموزش دهنده اشتباه کرد دیگه؟

خیر.

چون وقتی کلید خارجیِ Food_Id را درون جدول Recipt گذاشت ، یعنی جدول Recipt ، متعلق (و در EF ، عضوی از) Food هست . در صورتی که "سفارش" ، متعلق به "غذا" نیست . بلکه "غذا" ، متعلق به "سفارش" هست ، به این معنا که هر سفارش ، میتونه یک یا چند غذا را شامل بشه . اما غذا که نمیتونه سفارش را شامل بشه .
درست میگم؟

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

 

[SajjadKhati]

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

سلامی مجدد استاد .
خیلی ممنون (همچنین از جواب بقیه ی قسمت ها) .

الان استاد تعریف کلید خارجی در سایت زیر را ببینید :

SQL FOREIGN KEY Constraint

W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering popular subjects like HTML, CSS, JavaScript, Python, SQL, Java, and many, many more.

www.w3schools.com

A FOREIGN KEY is a field (or collection of fields) in one table, that refers to the PRIMARY KEY in another table.

The table with the foreign key is called the child table, and the table with the primary key is called the referenced or parent table.

گفته که جدولی که درونش کلید خارجی وجود داشته باشه ، اون جدول ، جدول فرزند نامیده میشه و جدولی که کلید اصلی توش وجود داشته باشه (که کلید خارجیِ جدول دیگه ، به کلید اصلی این جدول اشاره میکنه) ، جدول والد نامیده میشه .

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

اما با این حال ، شما هم درست میگید که جدول غذا باید جدا باشه تا از اول ، هم نام غذا و قیمت داشته باشه و هم با حذف سفارش مشتری ، رکوردهای جدول غذا نباید حذف بشه .

اما من قاتی کردم .
اگه اشتباه نکنم ، توصیفاتی که درباره ی جداول Customers و Recipt در پست قبلی کرده بودم (قضیه ی تعلق گرفتن و عضو بودن کلاس Recipt به Customers در EF و تشابه اش در جداول) ، احتمالا درست هست (با توجه به نکته ای که در لینک بالا گفته و همچنین روابط کلاس ها و مدل سازی در EF) .
درست میگم؟

اما همچنان روابط بین جدول Food و Recipt را به خوبی نمیتونم تحلیل کنم . هر چند با توضیحاتی که دادید ، متوجه ی قضیه شدم .
اما فرضا اگه خودم میخواستم همچین جداولی را طراحی کنم ، همچین نکته ای که گفته بودید ، به ذهنم نمیرسید و فرضا کلید خارجی را در جدول Food تعریف میکردم (تا به جدول Recipt اشاره کنه) .

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

بی زحمت یه توضیحی درباره ی کلیات این قضیه میدین که طرز تجزیه و تحلیل و ایجاد جداول و روابط شون و علی الخصوص کلید خارجی در جداول را باید چجوری تعیین کرد و کلید خارجی را از کجا متوجه میشید که در کدوم جدول قرار بدید؟

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

الان فرضا شما میگید کلید خارجیِ Food_Id باید در همون جدول Recipt انجام بشه ، از کجا دونستید؟
یعنی از کجا بدونم که این کلید را در جدول Food نذارم؟ و اگه این کلید خارجی را در جدول Food بذارم ، فرقش با اینکه در Recipt هست ، چیه؟

کلا متوجه ی منظورم شدید استاد؟
تشکر استاد .

 

[the_king]

سلامی مجدد استاد .
خیلی ممنون (همچنین از جواب بقیه ی قسمت ها) .

الان استاد تعریف کلید خارجی در سایت زیر را ببینید :

SQL FOREIGN KEY Constraint

W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering popular subjects like HTML, CSS, JavaScript, Python, SQL, Java, and many, many more.

www.w3schools.com

گفته که جدولی که درونش کلید خارجی وجود داشته باشه ، اون جدول ، جدول فرزند نامیده میشه و جدولی که کلید اصلی توش وجود داشته باشه (که کلید خارجیِ جدول دیگه ، به کلید اصلی این جدول اشاره میکنه) ، جدول والد نامیده میشه .

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

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

اما با این حال ، شما هم درست میگید که جدول غذا باید جدا باشه تا از اول ، هم نام غذا و قیمت داشته باشه و هم با حذف سفارش مشتری ، رکوردهای جدول غذا نباید حذف بشه .

اما من قاتی کردم .
اگه اشتباه نکنم ، توصیفاتی که درباره ی جداول Customers و Recipt در پست قبلی کرده بودم (قضیه ی تعلق گرفتن و عضو بودن کلاس Recipt به Customers در EF و تشابه اش در جداول) ، احتمالا درست هست (با توجه به نکته ای که در لینک بالا گفته و همچنین روابط کلاس ها و مدل سازی در EF) .
درست میگم؟

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

اما همچنان روابط بین جدول Food و Recipt را به خوبی نمیتونم تحلیل کنم . هر چند با توضیحاتی که دادید ، متوجه ی قضیه شدم .
اما فرضا اگه خودم میخواستم همچین جداولی را طراحی کنم ، همچین نکته ای که گفته بودید ، به ذهنم نمیرسید و فرضا کلید خارجی را در جدول Food تعریف میکردم (تا به جدول Recipt اشاره کنه) .

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

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

بی زحمت یه توضیحی درباره ی کلیات این قضیه میدین که طرز تجزیه و تحلیل و ایجاد جداول و روابط شون و علی الخصوص کلید خارجی در جداول را باید چجوری تعیین کرد و کلید خارجی را از کجا متوجه میشید که در کدوم جدول قرار بدید؟

کلیات بدرد نمیخوره، باید مدل سازی اش رو یاد بگیرید. ده تا مثال هم شرح بدم کافی نیست، اصولش رو باید یاد بگیرید. دیگه از جزوه خلاصه شده که خلاصه تر نمیشه.
شما یک مشتری دارید که سفارش غذا میده، مشتری یکسری داده مشخص داره که ربطی به سفارش های متعدد اش نداره، مثل کد و نام و شماره تلفن و ... اینها یک موجودیت x ئه. برای هر سفارش اش یک کد میخواد، آیا میتونه این کد جزئی از x باشه؟ نه، چون هر مشتری ممکنه هزار سفارش داشته باشه، دلیلی نداره برای هر رکورد سفارش مجددا نام و شماره تلفن و ... ثبت بشه. پس کد سفارش و تاریخ سفارش و محل تحویل و نحوه پرداخت و ... در یک موجودیت y قرار میگیره که کد مشتری رو به عنوان کلید خارجی داره. حالا هر سفارش شامل چند غذا است؟ فرضا میتونه ده تا غذا هم در یک سفارش باشه. آیا باید کد غذا ها باید در همون موجودیت y باشه؟ طبعا اون مشخصات y نباید برای هر قلم داخل سفارش تکرار بشن، پس نه، یک موجودیت z میخواد که مشخص کنه در قلم سفارش ای با کد منحصر بفرد فلان و کد سفارش بهمان، غذای کد فلان با تعداد بهمان و قیمت فلان و ... ثبت شده.
غذا و مشخصات غذا هم که برای خودش یک موجودیت دیگه است. پس برای مشخصات مشتری و سفارش هایش سه تا جدول لازم بود به علاوه جدول مشخصات غذا.
حالا موجودیت z متعلق به y ئه، چون اگر سفارش با کد فلان نباشه، اقلام داخل اون سفارش معنی ندارند. اگر مشتری با کد فلان نباشه، سفارش هایش هم معنی ندارند، پس y هم به x تعلق داره. اما غذا و مشتری مستقل هستند، چه سفارشی در کار باشه و چه نباشه هستند.

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

یک راه بیشتر نداره، اصول طراحی پایگاه داده ها رو بخونید و یاد بگیرید.

الان فرضا شما میگید کلید خارجیِ Food_Id باید در همون جدول Recipt انجام بشه ، از کجا دونستید؟

هر رکورد غذا باید با 0 الی N سفارش در ارتباط باشه، اگر رکورد غذا شامل کلید سفارش باشه که میشه رابطه با 0 الی 1 سفارش. چون دیگه یک رکورد نمیتونه با صد سفارش در ارتباط باشه، فقط یک کد سفارش رو میتونه ثبت کنه.

یعنی از کجا بدونم که این کلید را در جدول Food نذارم؟ و اگه این کلید خارجی را در جدول Food بذارم ، فرقش با اینکه در Recipt هست ، چیه؟

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

 

[SajjadKhati]

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

سلامی مجدد
خیلی ممنون استاد از توضیحات کامل تون

اما استاد ، طبق توضیح خودتون که در ادامه هم اشاره میکنم ، من درست حدس زدم (هر چند با اندکی اشتباه ، اما کلیاتش را درست حدس زدم) .

یعنی طبق ادامه ی توضیحات خودتون ، این عکس طراحی جداول که در پست 108 دادم که اون آموزش دهنده داده بود ، اولا خودتون در پایین اشاره کردید که برای اینها ، 3 تا جدول نیاز هست ، اون هم جدای از جدول غذا .

یعنی با جدول غذا ، کلا میشن 4 تا جدول (من هم تقریبا همین موضوع را با اشتباه گفتم . یعنی اون 3 تا جدولی که شما در زیر اشاره کردید ، من هم همون ها را در پست 108 گفتم که اون طور باید طراحی بشن که شما هم اشاره کردید) .
منتها من یک جا را اشتباه کردم و اون اینکه جدول سوم را برابر با جدول غذا گرفتم اما شما در توضیحات تون ، این جدولی که من اشاره کردم را به عنوان جدول z در نظر گرفتید . البته اشتباه دیگه من هم این بود که جدول غذا را جداگانه در نظر نگرفتم .

نکته اینه که اصلا این جدول z ای که شما اشاره کردید (که جدولی برای سفارش غذا هست و در ارتباط با جدول y که اشاره کردید که همون جدول Recipt هست) ، با جدول غذا اصلا ارتباطی به معنای کلید خارجی نباید داشته باشن . یعنی نه در جدول z ، نباید هیچ کلید خارجی ای وجود داشته باشه که به جدول Food اشاره کنه و نه در جدول Food نیاز هست که هیچ کلید خارجی ای وجود داشته باشه که به جدول z اشاره کنه .
درست میگم؟

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

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

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

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

تشکر استاد

شما یک مشتری دارید که سفارش غذا میده، مشتری یکسری داده مشخص داره که ربطی به سفارش های متعدد اش نداره، مثل کد و نام و شماره تلفن و ... اینها یک موجودیت x ئه.

این موجودیت های x ، همون فیلدهایی هستن که در جدول Customers در پست 108 هستن . درسته؟
تا اینجا را مشکلی ندارم .

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

این موجودیت های y ، همون فیلدهایی هستن که در جدول Recipt در پست 108 هستن . درسته؟
تا اینجا هم حدودا مشکلی ندارم .
هر چند با فیلد Food_Id در این جدول مخالفم .

پس تا اینجا ، چون هر موجودیت در Customers ، بیش از یک مقدار در Recipt میتونه داشته باشه ، یه جدول جداگانه براش در نظر میگیریم .

این ، همونی بود که در مدل سازی کلاس EF ، میگفتم که در کلاس Customers ، چون برای Recipt آرایه یا کالکشن وجود داره (کالکشن ای از Recipt وجود داره) ، یعنی ممکنه به ازای هر Customers ، بیش از یک مقدار برای Recipt وجود داشته باشه ، پس جدول Recipt را در طراحی پایگاه داده ، جدا میکنیم .
درسته؟

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

خوب ، این موجودیت های و فیلدهای z ، دقیقا میگید که اینها در یه جدولی جداگانه باید باشن که این جدول ، اصلا در پست شماره 108 اشاره نشد . درست میگم؟

یعنی میگید که در اون عکس پست 108 ، یه جدولی فرضا بنام FoodOrder باید باشه (که برای سفارشات غذای مربوط به مشتری باشه) که اولا کلید خارجی ای توش باشه که به جدول Recipt اشاره کنه و دوما شامل موجودیت ها و فیلدهایی که تحت عنوان z یاد کردین باشه .
درست متوجه شدم؟

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

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

غذا و مشخصات غذا هم که برای خودش یک موجودیت دیگه است. پس برای مشخصات مشتری و سفارش هایش سه تا جدول لازم بود به علاوه جدول مشخصات غذا.

که کلا 4 تا جدول میشن .
پس طراحی جداول پست 108 ، درست نبود دیگه .
در واقع کامل نبود دیگه .
درسته؟

و نکته ی مهم اینجاست که اصلا لازم نیست کلید خارجی ای در جدول Recipt وجود داشته باشه که به جدول Food اشاره کنه (فیلد Food_Id در جدول Recipt لازم نیست) .
درست میگم؟

حالا موجودیت z متعلق به y ئه، چون اگر سفارش با کد فلان نباشه، اقلام داخل اون سفارش معنی ندارند.

بله . همین رو میگم .
یعنی جدول FoodOrder (که در پاراگراف قبلی ، اسم اش را به این نام گذاشتم که موجودیت ها و فیلدهای z ای که اشاره کردین را توی این جدول داره) ، متعلق به (فرزندِ) جدول Recipt هست .

یعنی در جدول FoodOrder ، کلید خارجی ای وجود داره که به جدول Recipt اشاره میکنه . اما کلید خارجی ای در این جدول نیست که به جدول Food اشاره کنه .
درست میگم؟

این دقیقا همون چیزی بود که در پست 108 گفته بودم که یا اون اشتباه کرد ، یا من قاتی کردم .

اگر مشتری با کد فلان نباشه، سفارش هایش هم معنی ندارند، پس y هم به x تعلق داره.

یعنی جدول Recipt متعلق و فرزندِ جدول Customers هست که درسته .

اما غذا و مشتری مستقل هستند، چه سفارشی در کار باشه و چه نباشه هستند.

یعنی جدول Food ، جدولی جداست که نکته ی مهم اش اینه که هیچ ارتباطی با بقیه ی جداول نداره . یعنی هیچ کلید خارجی ای نباید توی این جدول تعریف بشه .
چرا؟

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

یک راه بیشتر نداره، اصول طراحی پایگاه داده ها رو بخونید و یاد بگیرید.

هر رکورد غذا باید با 0 الی N سفارش در ارتباط باشه، اگر رکورد غذا شامل کلید سفارش باشه که میشه رابطه با 0 الی 1 سفارش. چون دیگه یک رکورد نمیتونه با صد سفارش در ارتباط باشه، فقط یک کد سفارش رو میتونه ثبت کنه.

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

خیلی ممنون استاد از توضیحات مفصل تون .

 

[the_king]

سلامی مجدد
خیلی ممنون استاد از توضیحات کامل تون

اما استاد ، طبق توضیح خودتون که در ادامه هم اشاره میکنم ، من درست حدس زدم (هر چند با اندکی اشتباه ، اما کلیاتش را درست حدس زدم) .

یعنی طبق ادامه ی توضیحات خودتون ، این عکس طراحی جداول که در پست 108 دادم که اون آموزش دهنده داده بود ، اولا خودتون در پایین اشاره کردید که برای اینها ، 3 تا جدول نیاز هست ، اون هم جدای از جدول غذا .

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

نکته اینه که اصلا این جدول z ای که شما اشاره کردید (که جدولی برای سفارش غذا هست و در ارتباط با جدول y که اشاره کردید که همون جدول Recipt هست) ، با جدول غذا اصلا ارتباطی به معنای کلید خارجی نباید داشته باشن . یعنی نه در جدول z ، نباید هیچ کلید خارجی ای وجود داشته باشه که به جدول Food اشاره کنه و نه در جدول Food نیاز هست که هیچ کلید خارجی ای وجود داشته باشه که به جدول z اشاره کنه .
درست میگم؟

خیر. غذای کد فلان کلید خارجی مرتبط با کد غذا است، مگر میشه چلوکباب سفارش داده بشه در صورتی که غذایی به نام چلوکباب به ثبت نرسیده؟

شما یک مشتری دارید که سفارش غذا میده، مشتری یکسری داده مشخص داره که ربطی به سفارش های متعدد اش نداره، مثل کد و نام و شماره تلفن و ... اینها یک موجودیت x ئه. برای هر سفارش اش یک کد میخواد، آیا میتونه این کد جزئی از x باشه؟ نه، چون هر مشتری ممکنه هزار سفارش داشته باشه، دلیلی نداره برای هر رکورد سفارش مجددا نام و شماره تلفن و ... ثبت بشه. پس کد سفارش و تاریخ سفارش و محل تحویل و نحوه پرداخت و ... در یک موجودیت y قرار میگیره که کد مشتری رو به عنوان کلید خارجی داره. حالا هر سفارش شامل چند غذا است؟ فرضا میتونه ده تا غذا هم در یک سفارش باشه. آیا باید کد غذا ها باید در همون موجودیت y باشه؟ طبعا اون مشخصات y نباید برای هر قلم داخل سفارش تکرار بشن، پس نه، یک موجودیت z میخواد که مشخص کنه در قلم سفارش ای با کد منحصر بفرد فلان و کد سفارش بهمان، غذای کد فلان با تعداد بهمان و قیمت فلان و ... ثبت شده.
غذا و مشخصات غذا هم که برای خودش یک موجودیت دیگه است. پس برای مشخصات مشتری و سفارش هایش سه تا جدول لازم بود به علاوه جدول مشخصات غذا.

تشکر استاد
این موجودیت های x ، همون فیلدهایی هستن که در جدول Customers در پست 108 هستن . درسته؟

بله.

این موجودیت های y ، همون فیلدهایی هستن که در جدول Recipt در پست 108 هستن . درسته؟

بله.

این ، همونی بود که در مدل سازی کلاس EF ، میگفتم که در کلاس Customers ، چون برای Recipt آرایه یا کالکشن وجود داره (کالکشن ای از Recipt وجود داره) ، یعنی ممکنه به ازای هر Customers ، بیش از یک مقدار برای Recipt وجود داشته باشه ، پس جدول Recipt را در طراحی پایگاه داده ، جدا میکنیم .
درسته؟

بله.

خوب ، این موجودیت های و فیلدهای z ، دقیقا میگید که اینها در یه جدولی جداگانه باید باشن که این جدول ، اصلا در پست شماره 108 اشاره نشد . درست میگم؟

اینهایی که شما میگید برای مدلی است که من دارم توصیف می کنم که هر سفارش بیش از یک قلم جنس داره، در مدل ای که هر سفارش یک قلم جنس داره که نباید دنبال مواردی بگردید که من توصیف کردم.

یعنی میگید که در اون عکس پست 108 ، یه جدولی فرضا بنام FoodOrder باید باشه (که برای سفارشات غذای مربوط به مشتری باشه) که اولا کلید خارجی ای توش باشه که به جدول Recipt اشاره کنه و دوما شامل موجودیت ها و فیلدهایی که تحت عنوان z یاد کردین باشه .

بله ولی نه برای اون مدل که شما جایی دیگری خوندید. برای مدلی که من توصیف کردم که هر سفارش چندین غذا رو شامل میشه. من مدلی که یک نفر دیگه توصیف کرده رو که نمی تونم تغییر بدم، در اون مدل هر سفارش یک قلم غذا داشته، نیازی هم به جدول FoodOrder نداشته.

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

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

دوما این جدول FoodOrder ، لازم نیست هیچ کلید خارجی ای داشته باشه که به جدول Food اشاره کنه .

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

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

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

که کلا 4 تا جدول میشن .
پس طراحی جداول پست 108 ، درست نبود دیگه .

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

در واقع کامل نبود دیگه .

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

درسته؟

خیر.

و نکته ی مهم اینجاست که اصلا لازم نیست کلید خارجی ای در جدول Recipt وجود داشته باشه که به جدول Food اشاره کنه (فیلد Food_Id در جدول Recipt لازم نیست) .
درست میگم؟

این قواعد عجیب و غریب رو از چه مطالبی استخراج میکنید؟

 

[SajjadKhati]

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

اینهایی که شما میگید برای مدلی است که من دارم توصیف می کنم که هر سفارش بیش از یک قلم جنس داره، در مدل ای که هر سفارش یک قلم جنس داره که نباید دنبال مواردی بگردید که من توصیف کردم.

بله ولی نه برای اون مدل که شما جایی دیگری خوندید. برای مدلی که من توصیف کردم که هر سفارش چندین غذا رو شامل میشه. من مدلی که یک نفر دیگه توصیف کرده رو که نمی تونم تغییر بدم، در اون مدل هر سفارش یک قلم غذا داشته، نیازی هم به جدول FoodOrder نداشته.

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

سلامی مجدد استاد .
خیلی ممنون .

استاد ، مگه سفارش غذا ، ممکنه که بیش از یکی نشه؟!
الان فرضا من برم غذا سفارش بدم ، نمیگم فقط ساندویچ میخوام که
2 تا سس ، یه دوغ ، و ایناها هم همراش هست دیگه . اینا نباشه ، نمک که حداقل هست .

فرضا من چند نوع غذا را همزمان نخوام ، چه تضمینی هست که یه نفر دیگری ، فقط یه نوع غذا بخواد؟

فرضا اگه آموزش دهنده هم فقط یک نوع غذا را مد نظر داشت ، باید اعلام میکرد دیگه .
برای کم کردن جدول هم باز هم روش های دیگه هم هست . فرضا هر مشتری ، فقط بتونه یک سفارش بده . نیاز به جدول Recipt هم نداره .

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

خیر. غذای کد فلان کلید خارجی مرتبط با کد غذا است، مگر میشه چلوکباب سفارش داده بشه در صورتی که غذایی به نام چلوکباب به ثبت نرسیده؟



بله.

بله.

بله.

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

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

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

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

خیر.

این قواعد عجیب و غریب رو از چه مطالبی استخراج میکنید؟

استاد ، من نظرم را میگم ، شما بگید کجا اشتباه میکنم ؟
ببینید ، جدول Food ، داده ای داره که فقط نیازه که در برنامه پردازش بشه . نیازی به ارتباط جدول Food با بقیه ی جداول نیست .

فرض کنید که در جدول Food ، یه فیلد ID و یه فیلد Name و فیلد RemainNumber (که تعداد اون غذای باقی مانده را میگه که چند تاست) داریم .
غذایی بنام چلوکباب ، با شماره ی 2 ، به تعداد 10 تا باقی مونده .

خوب حالا برنامه ، موقعی که هر مشتری سفارش میده ، ابتدا ، اطلاعات جدول Food را چک میکنه که آیا تعداد باقی مانده ی اون غذا (فیلد RemainNumber) ، به صِفر رسید یا نه و اگه 0 بود ، نمیتونه سفارش بده . اگه صفر نبود ، خوب سفارش اش را میده و بعد در رکوردهای دیتابیس در جدول ذخیره میکنه (یا فرضا فیلد RemainNumber هم نبود و بجای این فیلد ، کلا رکورد و اطلاعات اون غذا را حذف کنن) .

به این ترتیب ، هر سفارشی که قبلا داده شد ، در همون موقعی که داشت سفارش میداد ، اون غذا وجود داشت (حالا چه تعداد غذای باقی مانده ، بعد از سفارش دادن ، بخواد تمام شده باشه یا نشده باشه یا اینکه بعد از سفارش ، اون غذا موجود باشه یا نباشه) .
متوجه ی منظورم شدید؟

بنابراین ارتباط کلید خارجی ای نیاز نیست که در جدول Food یا جدول FoodOrder (که درباره ی این جدول ، در پست قبلی ام نوشتم) وجود داشته باشه که به همدیگه اشاره کنن .

اگه این چیزی که گفتم اشکال داره ، کجاش اشکال داره؟
تشکر استاد .

 

[the_king]

سلامی مجدد استاد .
خیلی ممنون .

استاد ، مگه سفارش غذا ، ممکنه که بیش از یکی نشه؟!

الان فرضا من برم غذا سفارش بدم ، نمیگم فقط ساندویچ میخوام که
2 تا سس ، یه دوغ ، و ایناها هم همراش هست دیگه . اینا نباشه ، نمک که حداقل هست .

فرضا من چند نوع غذا را همزمان نخوام ، چه تضمینی هست که یه نفر دیگری ، فقط یه نوع غذا بخواد؟

فرضا اگه آموزش دهنده هم فقط یک نوع غذا را مد نظر داشت ، باید اعلام میکرد دیگه .
برای کم کردن جدول هم باز هم روش های دیگه هم هست . فرضا هر مشتری ، فقط بتونه یک سفارش بده . نیاز به جدول Recipt هم نداره .

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

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

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

استاد ، من نظرم را میگم ، شما بگید کجا اشتباه میکنم ؟
ببینید ، جدول Food ، داده ای داره که فقط نیازه که در برنامه پردازش بشه . نیازی به ارتباط جدول Food با بقیه ی جداول نیست .

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

فرض کنید که در جدول Food ، یه فیلد ID و یه فیلد Name و فیلد RemainNumber (که تعداد اون غذای باقی مانده را میگه که چند تاست) داریم .
غذایی بنام چلوکباب ، با شماره ی 2 ، به تعداد 10 تا باقی مونده .

این RemainNumber از کجا اومد؟ شما برای خودتون مدل جدید تعریف کرده اید، بعد میخواهید ربطش بدهید به پایگاه داده متناسب با مدل دیگری؟

خوب حالا برنامه ، موقعی که هر مشتری سفارش میده ، ابتدا ، اطلاعات جدول Food را چک میکنه که آیا تعداد باقی مانده ی اون غذا (فیلد RemainNumber) ، به صِفر رسید یا نه و اگه 0 بود ، نمیتونه سفارش بده . اگه صفر نبود ، خوب سفارش اش را میده و بعد در رکوردهای دیتابیس در جدول ذخیره میکنه (یا فرضا فیلد RemainNumber هم نبود و بجای این فیلد ، کلا رکورد و اطلاعات اون غذا را حذف کنن) .

به این ترتیب ، هر سفارشی که قبلا داده شد ، در همون موقعی که داشت سفارش میداد ، اون غذا وجود داشت (حالا چه تعداد غذای باقی مانده ، بعد از سفارش دادن ، بخواد تمام شده باشه یا نشده باشه یا اینکه بعد از سفارش ، اون غذا موجود باشه یا نباشه) .
متوجه ی منظورم شدید؟

بنابراین ارتباط کلید خارجی ای نیاز نیست که در جدول Food یا جدول FoodOrder (که درباره ی این جدول ، در پست قبلی ام نوشتم) وجود داشته باشه که به همدیگه اشاره کنن .

اگه این چیزی که گفتم اشکال داره ، کجاش اشکال داره؟
تشکر استاد .

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

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

 

[SajjadKhati]

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

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

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

این RemainNumber از کجا اومد؟ شما برای خودتون مدل جدید تعریف کرده اید، بعد میخواهید ربطش بدهید به پایگاه داده متناسب با مدل دیگری؟

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

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

خیلی ممنون استاد .
الان پس شما میگید که این آموزش دهنده ، این نوع مدل تک غذا را در نظر گرفت . (حالا من میگم حداقل یه توضیحی میداد که مدل من ، فرضا تک غذا هست . حالا بماند) .

نکته ای که واسه ی من هست ، کلید خارجیِ Food_Id در جدول Recipt هست .
این رو شما میگید بخاطر این به عنوان کلید خارجی تعیین شد که فرضا اگه غذای شماره ی 2 در جدول Food وجود نداشت ، غذای جدیدی با این شماره ، در جدول Recipt ، ثبت نشه؟

یعنی یکی از موارد مهمی که وظیفه ی کلید خارجی هست اینه که اگه رکوردی در جدول والد وجود نداره (رکورد مربوط به فیلد کلید اصلی در جدول والد وجود نداره) ، اطلاعات مربوط به اون رکورد در جدول فرزند (یعنی همون جدولی که فیلدی به عنوان کلید خارجی تعیین شد) هم ثبت نشه .

درست میگم؟
تشکر استاد .

 

[the_king]

خیلی ممنون استاد .
الان پس شما میگید که این آموزش دهنده ، این نوع مدل تک غذا را در نظر گرفت . (حالا من میگم حداقل یه توضیحی میداد که مدل من ، فرضا تک غذا هست . حالا بماند) .

نکته ای که واسه ی من هست ، کلید خارجیِ Food_Id در جدول Recipt هست .
این رو شما میگید بخاطر این به عنوان کلید خارجی تعیین شد که فرضا اگه غذای شماره ی 2 در جدول Food وجود نداشت ، غذای جدیدی با این شماره ، در جدول Recipt ، ثبت نشه؟

غذای جدید از کجا میتونه داخل Recipt بیاد وقتی هنوز در جدول Food ثبت نشده؟
نه. در جدول مقدار کلید منحصر بفرد ئه، پس اینکه کلید جدول Food یا سایر جداول مقادیر یکتا دارند که بدیهی است.
سفارش از بین غذاهای به ثبت رسیده انجام میشه، نام، نوع و قیمت تون از طریق اون جدول غذا مشخص شده، فردا که سیستم روشن شد مشخص باشه که قبلا چه غذایی سفارش داده شده بود. سابقه اون سفارش بر اساس کد غذا میتونه بگه دیروز در سفارش فلان، غذای بهمان از نوع فلان ثبت شده.
یا میگه دیروز در مجموع n پرس چلوکباب فروخته شده، در مجموع m مورد از نوع پیش غذا فروخته شده.
یا اگر نام غذای سوپ امروز به سوپ جو تغییر کرد، در گزارش سوابق فروش هفته پیش هم همون نام جدید نمایش داده میشه.
اگر نوع غذای چلوکباب از سنتی به غذای اصلی تغییر کرد، همه رکورد های جدول Recipt که هفته گذشته چلوکباب فروخته اند در آمار غذاهای اصلی هست.

یعنی یکی از موارد مهمی که وظیفه ی کلید خارجی هست اینه که اگه رکوردی در جدول والد وجود نداره (رکورد مربوط به فیلد کلید اصلی در جدول والد وجود نداره) ،

درست میگم؟

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

 

[SajjadKhati]

غذای جدید از کجا میتونه داخل Recipt بیاد وقتی هنوز در جدول Food ثبت نشده؟
نه. در جدول مقدار کلید منحصر بفرد ئه، پس اینکه کلید جدول Food یا سایر جداول مقادیر یکتا دارند که بدیهی است.
سفارش از بین غذاهای به ثبت رسیده انجام میشه، نام، نوع و قیمت تون از طریق اون جدول غذا مشخص شده، فردا که سیستم روشن شد مشخص باشه که قبلا چه غذایی سفارش داده شده بود. سابقه اون سفارش بر اساس کد غذا میتونه بگه دیروز در سفارش فلان، غذای بهمان از نوع فلان ثبت شده.
یا میگه دیروز در مجموع n پرس چلوکباب فروخته شده، در مجموع m مورد از نوع پیش غذا فروخته شده.
یا اگر نام غذای سوپ امروز به سوپ جو تغییر کرد، در گزارش سوابق فروش هفته پیش هم همون نام جدید نمایش داده میشه.
اگر نوع غذای چلوکباب از سنتی به غذای اصلی تغییر کرد، همه رکورد های جدول Recipt که هفته گذشته چلوکباب فروخته اند در آمار غذاهای اصلی هست.

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

سلامی مجدد
خیلی ممنون استاد .

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

استاد ، احتمالا بصورت سهوی جای جدول والد و جدول فرزند را اشتباه نوشتید (یا چیز دیگه ای باشه که من اطلاع ندارم رو نمیدونم) :

SQL Server: Foreign Keys

This SQL Server tutorial explains how to use Foreign Keys in SQL Server with syntax and examples. A foreign key is a way to enforce referential integrity within your SQL Server database. A foreign key means that values in one table must also appear in another table.

www.techonthenet.com

SQL FOREIGN KEY Constraint

W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering popular subjects like HTML, CSS, JavaScript, Python, SQL, Java, and many, many more.

www.w3schools.com

The referenced table is called the parent table while the table with the foreign key is called the child table.

The table with the foreign key is called the child table, and the table with the primary key is called the referenced or parent table.

که میگن جدولی که کلید خارجی توش باشه ، جدول فرزند و جدولی که (کلید خارجی ای در یه جدول دیگه) بهش مرجع و رجوع داده شده باشه ، جدول والد نام داره .

بنابراین جدول شهر شما ، جدول والد و جدول شهروندتون ، جدول فرزند هست .

شما این قواعد عجیب و غریب رو از کدوم مطلب میارید؟

Primary and Foreign Key Constraints - SQL Server

Primary and Foreign Key Constraints

learn.microsoft.com

For example, the Sales.SalesOrderHeader table has a foreign key link to the Sales.SalesPerson table because there is a logical relationship between sales orders and salespeople. The SalesPersonID column in the SalesOrderHeader table matches the primary key column of the SalesPerson table. The SalesPersonID column in the SalesOrderHeader table is the foreign key to the SalesPerson table.

By creating this foreign key relationship, a value for SalesPersonID cannot be inserted into the SalesOrderHeader table if it does not already exist in the SalesPerson table.

در اینجا توضیح داده که یه جدول بنام SalesOrderHeader وجود داره که ستونی بنام SalesPersonID داره که این ستون ، به عنوان کلید خارجی ای هست که به جدول SalesPerson اشاره میکنه .

در ادامه هم توضیح داده که وقتی این ارتباط کلید خارجی را تعریف میکنیم ، اگه یه مقدار ، قبلا درون جدول SalesPerson موجود نبوده باشه ، اون مقدار نمیتونه در ستون SalesPersonID (در جدول SalesOrderHeader) ثبت بشه .

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

پس میشه نتیجه گرفت که یکی از موارد کاربرد تعریف کلید خارجی اینه که وقتی ، مقداری و رکوردی که در ستون جدول والدش از قبل وجود نداره ، باعث میشه که در جدول فرزند (جدولی که کلید خارجی درون اون تعریف شد) هم اون مقدار ثبت نشه .
که اگه این طور نباشه و در این صورت ، در جدول فرزند ثبت بشه ، این عمل ، مصداق این هست که ارتباط بین دو جدول را از بین میبره . و تعریف کلید خارجی هم برای جلوگیری از اعمالی هست که باعث قطع ارتباط دو جدول بشه :

SQL FOREIGN KEY Constraint

W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering popular subjects like HTML, CSS, JavaScript, Python, SQL, Java, and many, many more.

www.w3schools.com

The FOREIGN KEY constraint is used to prevent actions that would destroy links between tables.

درسته ؟
تشکر استاد .

 

[the_king]

سلامی مجدد
خیلی ممنون استاد .



استاد ، احتمالا بصورت سهوی جای جدول والد و جدول فرزند را اشتباه نوشتید (یا چیز دیگه ای باشه که من اطلاع ندارم رو نمیدونم) :

بله، اشتباه نوشتم.

SQL Server: Foreign Keys

This SQL Server tutorial explains how to use Foreign Keys in SQL Server with syntax and examples. A foreign key is a way to enforce referential integrity within your SQL Server database. A foreign key means that values in one table must also appear in another table.

www.techonthenet.com

SQL FOREIGN KEY Constraint

W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering popular subjects like HTML, CSS, JavaScript, Python, SQL, Java, and many, many more.

www.w3schools.com

که میگن جدولی که کلید خارجی توش باشه ، جدول فرزند و جدولی که (کلید خارجی ای در یه جدول دیگه) بهش مرجع و رجوع داده شده باشه ، جدول والد نام داره .

بنابراین جدول شهر شما ، جدول والد و جدول شهروندتون ، جدول فرزند هست .

Primary and Foreign Key Constraints - SQL Server

Primary and Foreign Key Constraints

learn.microsoft.com

در اینجا توضیح داده که یه جدول بنام SalesOrderHeader وجود داره که ستونی بنام SalesPersonID داره که این ستون ، به عنوان کلید خارجی ای هست که به جدول SalesPerson اشاره میکنه .

در ادامه هم توضیح داده که وقتی این ارتباط کلید خارجی را تعریف میکنیم ، اگه یه مقدار ، قبلا درون جدول SalesPerson موجود نبوده باشه ، اون مقدار نمیتونه در ستون SalesPersonID (در جدول SalesOrderHeader) ثبت بشه .

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

پس میشه نتیجه گرفت که یکی از موارد کاربرد تعریف کلید خارجی اینه که وقتی ، مقداری و رکوردی که در ستون جدول والدش از قبل وجود نداره ، باعث میشه که در جدول فرزند (جدولی که کلید خارجی درون اون تعریف شد) هم اون مقدار ثبت نشه .

این نتیجه گیری تون درسته، همچین کاربرد ای داره، از اون مطلب قبلی تون در مورد وظیفه کلید خارجی تفسیر دیگه ای کردم که اشتباه از من بود.

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

SQL FOREIGN KEY Constraint

W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering popular subjects like HTML, CSS, JavaScript, Python, SQL, Java, and many, many more.

www.w3schools.com

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

 

[SajjadKhati]

سلامی مجدد
خیلی ممنون استاد .

استاد ، در آموزش EF که میبینم ، اون جداول و موجودیت های قبلی را توسعه داد . به شکل های زیر در آورد :














سئوالم تقریبا مثل قبلی هست .
الان در این جداولی که رسم کرد ، جدول "غذا" ، از جدول "گروه غذا" جدا شد .

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

اما در اینجا ، جدول "گروه غذا" ، یه فیلد بنام "نام گروه" داره . خوب به ازای هر رکورد از غذا (که در جدول "غذا" ثبت میشه) ، امکان اضافه کردنِ چندین گروه وجود نداره . داره مگه؟
فرضا یه غذایی بنام "نوشابه" ، جزء گروهِ "نوشیدنی" هست . غذایی بنام "جوجه کباب" ، جزء گروه فرضا "سنتی" هست .
یعنی غذایی پیدا نمیشه که همزمان ، جزء 2 یا چند گروه باشه . پیدا میشه مگه؟

اگه نمیشه ، پس لازم نیست که جدول "گروه غذا" ، بصورت مجزا طراحی بشه .
میتونه فیلد "نام گروه" (در جدول "گروه غذا") ، درون همون جدول "غذا" تعریف بشه دیگه . درسته؟


یکی دیگه از شرایطی که جداول از هم جدا میشن ، اینه که کلا کارکردشون از هم جدا باشه . یعنی فرضا جدول "غذا" از جدول "سفارش غذا" ، اطلاعات شون از هم جداست چون وجود یا عدم وجود غذا (یا هر نوع اطلاعاتِ دیگه ی غذا) ، ربطی به سفارش غذا نداره (هر چند سفارش غذا ، بهش ربط داره) .

اینکه جدول "گروه غذا" را جدا کرد ، به این قضیه مربوط میشه؟
بعید به نظرم میرسه .

یا اینکه جدول "موجودی غذا" را هم از جدول "غذا" جدا کرد . این دیگه به چه علت بود؟!
میشه اطلاعات این جدول را درون همون جدول غذا نوشت دیگه؟
و همچنین جدول "واحد ها" و "گروه کاربران" و "گروه مشتریان" .

======================

سئوال دوم استاد ، همون شکل جدولی که در پست 108 دادم ، (در EF) وقتی به روش Database First داشت طراحی میکرد ، کدهایی که ویژال استودیو تولید کرد ، به شکل زیر بود :





شکل بالا ، به روش Database First طراحی شده (کدها هم توسط ویژال استودیو تولید شده) .
در شکل بالا ، کدهای کلاس مدل Customer هست .
ببینید ، شیِ (پروپرتی) Recipts ، در واقع یه کلید خارجی هست در جدول دیتابیس هست که در شکل پست 108 هم مشخص هست . این پروپرتی ، درون کلاس مدل Customer تعریف شد .
که به نظرم شکل درست اش همین هست . یعنی وقتی کدش را مینویسیم ، میگیم که Customer.Recipts . یعنی سفارشات مشتری ها ، جزء اعضای کلاس مشتری هستند دیگه .


حالا همون شکل جداول پست 108 را بصورت Code First طراحی کرد (این کدها را خود آموزش دهنده نوشت) :





الان در شکل بالا هم ، همون جدول پست 108 به این روش Code First طراحی شد .
یعنی شی (پروپرتی) customer در کلاس Recipt که در شکل بالا میبینید هم همون به عنوان کلید خارجی عمل میکنه!!
یعنی اعضای کلاس های مدل اش را دقیقا عین فیلدهای جداول اش (در پست 108) ، تعریف کرد !

این الان درسته؟
چون توی مدل که نباید این طوری باشه .
یعنی الان پروپرتیِ customer در شکل بالا ، یه کلید خارجی هست .
اما درون کلاس مدل Customer ، هیچ پروپرتی یا عضوی برای دسترسی به شیِ کلاس Recipt ، تعریف نکرد !!
یعنی برای دسترسی به Customer ، باید از طریق شی Recipt (یعنی پروپرتیِ Recipt.customer) عمل کنیم ؟!! (Customer که عضوی از Recipt نیست . بلکه برعکس هه) .

این الان واقعا درسته؟!! یا آموزش دهنده اشتباه کرد؟
اگه درسته ، بی زحمت توضیح میدین که چرا این جوری هست؟

یعنی سفارش ، که متعلق به مشتری هست ، به نظر میرسه که باید پروپرتی ای از جنس Recipt ، درون کلاس Customer تعریف بشه (مثل روش Database First که کدهاش را ویژال استودیو تولید کرد) ، پس این ، به چه دلیلی این طوری و در کلاس Recipt ، پروپرتی ای از نوع Customer تعریف کرد؟!
یا در صورت نیاز ، توضیحات بیشتر برای اینکار .

تشکر استاد .