سوال: آموزش طراحی نمودار ER ? [بایگانی]

sara.f

دوشنبه 16 فروردین 1389, 17:23 عصر

سلام
هر کدوم از دوستان که با طراحی نمودار ER اشنایی دارن و میتونن توضیح بدن اینجا لطف کنن راهنمایی کنن که جهت پیاده سازی این نمودار چکار کرد ؟ من موجودیت هامو تشخیص دادم (البته کامل نه )!+ صفت ها + کلید های هر موجودیت ! حالا باید چکار کنم ؟ ارتباطات رو ؟

سلام
برای طراحی نمودار ER، اول لازمه که تمام Entity ها را بشناسید.
تمامی Attribute های هر Entity را مشخص کنید، Pk ها را تعیین کنید.
حالا نوبت به طراحی relation ها میرسه.

و همون طور که می دونید، تمامی این مراحل را با توجه به نیازمندیهای نرم افزارتون می تونید انجام بدید.

majidmir

چهارشنبه 18 فروردین 1389, 12:10 عصر

سلام
برای طراحی نمودار ER، اول لازمه که تمام Entity ها را بشناسید.
تمامی Attribute های هر Entity را مشخص کنید، Pk ها را تعیین کنید.
حالا نوبت به طراحی relation ها میرسه.

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

sara.f

چهارشنبه 18 فروردین 1389, 13:13 عصر

سلام
من تمام موجودیت هام + صفت هاشون رو مخص کردم فقط مشکلم توی ارتباطات هستش کسی میتونه در مورد ارتباطات توضیح بده ؟
برای مثال در یه ویدیو کلوپ رابطه بین فروشنده (Admin ) با فیلم چیه ؟
فروشنده فیلم ها را خریداری میکند

فروشنده ، فیلم را خریداری می کند؟!!!! از کی خریداری می کنه؟
مگه در این ویدئو کلوپ، خریدار، فیلم را از فروشنده خریداری نمی کنه؟

javanerd

پنج شنبه 19 فروردین 1389, 10:19 صبح

برای مثال در یه ویدیو کلوپ رابطه بین فروشنده (Admin ) با فیلم چیه ؟
فروشنده فیلم ها را خریداری میکند

مشکل شما احتمالا این هست که به اشتباه فروشنده Admin رو جز موجودیت‌ها به شمار آوردید. در یک ویدیو کلوپ یک فروشنده وجود داره. لازم نیست که این یک تک فروشنده به صورت یک موجودیت مدل بشه. همون طور که لازم نیست خود ویدیو کلوپ به صورت یک موجودیت جدا مدل بشه.

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

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

در صورتی که این موجودیت جدید رو هم در نظر بگیریم، رابطه‌ی بین موجودیت‌ها به شکل زیر هست:

فروشنده یک یا چند فروش انجام می‌دهد -- هر فروش توسط یک فروشنده انجام می‌شود.
هر فروش شامل یک یا چند فیلم است -- هر فیلم در یک فروش به فروش می‌رسد.

البته باز هم توی این مدل یک موجودیت جا افتاده. در واقع باید بین موجودیت‌های «فیلم» و «نسخه‌ی موجود فیلم» تفاوت قایل شد. برای مثال موجودیت فیلم ممکنه برای مدل کردن فیلم «پدرخوانده» استفاده بشه. ولی «نسخه‌ی موجود فیلم» برای مدل کردن ۱۰ عدد سی‌دی یا دی‌وی‌دی که از این فیلم موجوده به کار میره. توجه کنید که همه‌ی این سی‌دی‌ها یا دی‌وی‌دی‌ها فیلم پدر خوانده هستند ولی ممکنه که یکی از سی‌دی‌ها آبی‌رنگ باشه و یکی نقره‌ای. یکی از سی‌دی‌ها توسط شرکت x رایت شده باشه و یکی دیگه توسط شرکت y. یکی از سی‌دی‌ها وضعیت ظاهری خوبی داشته باشه و یکی دیگه خش افتاده باشه. و توی مدل شما هم احتمالا لازم هست که تمام این اطلاعات ذخیره بشوند.

sara.f

پنج شنبه 19 فروردین 1389, 11:43 صبح

مشکل شما احتمالا این هست که به اشتباه فروشنده Admin رو جز موجودیت‌ها به شمار آوردید. در یک ویدیو کلوپ یک فروشنده وجود داره. لازم نیست که این یک تک فروشنده به صورت یک موجودیت مدل بشه.

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

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

در صورتی که این موجودیت جدید رو هم در نظر بگیریم، رابطه‌ی بین موجودیت‌ها به شکل زیر هست:

فروشنده یک یا چند فروش انجام می‌دهد -- هر فروش توسط یک فروشنده انجام می‌شود.
هر فروش شامل یک یا چند فیلم است -- هر فیلم در یک فروش به فروش می‌رسد.

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

و در مورد " فاکتور فروش" منم با شما موافقم و باید اون را به عنوان یک موجودیت در نظر گرفت و این خصوصیات را براش در نظر گرفت : تاریخ صدور، شماره فاکتور و....

خیلی خوب می شد که سایر دوستان هم در این مورد نظر خودشون را می گفتند، تا می تونستیم به بهترین طراحی ER برسیم.

majidmir

پنج شنبه 19 فروردین 1389, 13:18 عصر

sara.f

پنج شنبه 19 فروردین 1389, 13:51 عصر

سلام
** در مورد موجودیت بودن فروشنده ، من اون رو به عنوان موجودیت در نظر گرفتم اخه در این برنامه ای که قرار بنویسم چند تا فروشنده وجود داره ! فقط الان توی ارتباطش با فیلم مشکل دارم !
من خودم این رو کشیدم حالا شما لطف کنید ایراداتش رو بگید اون جاهایی رو هم که ؟ گذاشتم نمیدونستم باید چی بنویسم تا تکمیل بشه شما لطف کنید مشکلاتش رو به من بگید و اگه میشه تکمیل کنید !
http://www.freeuploadimages.org/images/9z1xwxm7lt55ide59xsv.jpg

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

majidmir

پنج شنبه 19 فروردین 1389, 17:06 عصر

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

javanerd

پنج شنبه 19 فروردین 1389, 17:55 عصر

ولی من اگر باشم، " فروش " را به عنوان یک رابطه در نظر می گرفتم، و نه یک موجودیت

کاملا با شما موافقم.

دلیل اینکه من بین یک رابطه و یک موجودیت تفاوتی قایل نشدم این بود که در نهایت همه‌ی این موجودیت‌ها و رابطه‌ها به صورت یک جدول در پایگاه داده یا یک کلاس در کد برنامه ظاهر می‌شوند.

majidmir

پنج شنبه 19 فروردین 1389, 19:10 عصر

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

javanerd

پنج شنبه 19 فروردین 1389, 19:38 عصر

من داشتم این طوری فکر می‌کردم.

http://barnamenevis.org/forum/picture.php?albumid=621&pictureid=1330

javanerd

پنج شنبه 19 فروردین 1389, 19:55 عصر

من فکر نمی کنم در نظر گرفتن یک موجودیت ارتباطی با تعداد آن داشته باشه، یعنی اینجا مهم اینه که موجودیتی به نام فروشنده وجود داره، چه یکی، چه دوتا، .....، چه صدتا.

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

majidmir

پنج شنبه 19 فروردین 1389, 20:26 عصر

سلام
دوستان بهتر نیست یه جمع بندی کلی بزنید و نمودار رو تکمیل کنیم ؟

sara.f

جمعه 20 فروردین 1389, 18:40 عصر

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

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

sara.f

جمعه 20 فروردین 1389, 18:44 عصر

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

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

sara.f

جمعه 20 فروردین 1389, 20:12 عصر

سلام
دوستان بهتر نیست یه جمع بندی کلی بزنید و نمودار رو تکمیل کنیم ؟

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

46793

majidmir

جمعه 20 فروردین 1389, 20:35 عصر

javanerd

جمعه 20 فروردین 1389, 20:35 عصر

هر جایی از این نمودار را که فکر می کنید مطابق با سیستم مورد نظر شما نیست ، بگید.
46793
برای اینکه اعضا بتونند فیلم‌ها رو کرایه کنند به یک رابطه بین member و movie نیاز داریم.

majidmir

جمعه 20 فروردین 1389, 20:38 عصر

برای اینکه بین اعضا بتونند فیلم‌ها رو کرایه کنند به یک رابطه بین member و movie نیاز داریم.
فک کنم این رابطه توسط فروشنده برقرار میشه و نیازی به رابطه مستقیم نیست :متفکر:

sara.f

جمعه 20 فروردین 1389, 20:49 عصر

برای اینکه بین اعضا بتونند فیلم‌ها رو کرایه کنند به یک رابطه بین member و movie نیاز داریم.

آره آره درسته، فراموش کردم این رابطه را در این شکله بکشم.
اصلش اینطوریه.

http://barnamenevis.org/forum/attachment.php?attachmentid=46796&stc=1&d=1270831731

javanerd

جمعه 20 فروردین 1389, 20:51 عصر

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

لطفا بقیه نظر بدهند.

majidmir

جمعه 20 فروردین 1389, 20:52 عصر

آره آره درسته، فراموش کردم این رابطه را در این شکله بکشم.
اصلش اینطوریه.

http://barnamenevis.org/forum/attachment.php?attachmentid=46796&stc=1&d=1270831731
به صورت غیر مستقیم نمیشه رابطه رو ایجاد کرد ؟

sara.f

جمعه 20 فروردین 1389, 20:57 عصر

سلام
به نظر من اینجوری بهتره چون نیازی به موجودیت عمده فروش نیست
فقط این قسمت رو که قرمز کردم روی ارتباطاتش باید توجه بشه اگه ما ID,NAME یه کاربر رو ثبت کنیم پس رابطه باید M باشه نه 1 (به نظر من !)

من منظور شما را متوجه نمی شم دوست عزیز.
این اعدادی که نوشتم کاری به خصوصیات موجودیتمون نداره، این رابطه 1~M که نوشتم معنیش اینه که هر فروشنده می تواند چندین عضو را بپذیرد یا محروم کند.

sara.f

جمعه 20 فروردین 1389, 21:02 عصر

به صورت غیر مستقیم نمیشه رابطه رو ایجاد کرد ؟

منظورتون از غیر مستقیم چیه؟ و کدوم رابطه را می گید؟

majidmir

شنبه 21 فروردین 1389, 11:28 صبح

من منظور شما را متوجه نمی شم دوست عزیز.
این اعدادی که نوشتم کاری به خصوصیات موجودیتمون نداره، این رابطه 1~M که نوشتم معنیش اینه که هر فروشنده می تواند چندین عضو را بپذیرد یا محروم کند.
وقتی که شما واسه فروشنده یه ID , NAME رو در نظر میگیرید یعنی چند فروشنده پس رابطه ما M~N میشه نه 1~M

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

اگه فقط من سه موجودیت عضو - فروشنده- فیلم رو در نظر بگیرم نه بیشتر نمودارم چطوری میشه ؟

نظر خودم روی این نموداره به نظرتون مشکلی داره یا نه ؟

sara.f

شنبه 21 فروردین 1389, 14:06 عصر

وقتی که شما واسه فروشنده یه ID , NAME رو در نظر میگیرید یعنی چند فروشنده پس رابطه ما M~N میشه نه 1~M

من بازم می گم که به نظر من ، ثبت خصوصیات یک موجودیت در DB ، دلیلی بر این نیست که تعداد این موجودیت بیشتر از یکی هست.
یعنی شما نمی تونید بگید چون مشخصات فروشنده ثبت میشه، یعنی حتما بیشتر از یک نفر هست. اگر من اشتباه می کنم، دوستان لطف کنند تصحیح کنند.
اما اگر خودتون فرض را بر این گذاشتید که تعداد فروشنده بیشتر از یکی هست، بله در اینصورت رابطه را می تونید به M~N تغییر بدید.

منظورم اینه که میشه فروشنده رو به عنوان یه رابط بین فیلم و عضو در نظر گرفت ؟ و توی رابطه عضو و مشتری تاریخ کرایه و مجوز ها رو ذخیره کنیم یعنی در واقع فقط از یه جدول رابطه ای استفاده کنیم ؟

اول اینکه منظورتون از رابطه عضو و مشتری چیه؟!!!
دوم اینکه رابط بودن فروشنده در این سیستم از نظر من بی معنیه، یعنی اینکه دو موجودیت مشتری( عضو) و فروشنده ، هر دو در اینجا Primary Actor هستند و رابطه مستقیم با ویدئو کلوپ دارند و وساطت این وسط معنی نداره.

اگه فقط من سه موجودیت [COLOR=Red]عضو - فروشنده- فیلم رو در نظر بگیرم نه بیشتر نمودارم چطوری میشه ؟

نظر خودم روی این نموداره به نظرتون مشکلی داره یا نه ؟

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

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

پیروز باشی.

http://barnamenevis.org/forum/attachment.php?attachmentid=46846&stc=1&d=1272096922

AZERILA

شنبه 28 فروردین 1389, 15:43 عصر

سلام
من مي خواستم بدونم اصلا اين نمودار ER چي هست اگه كسي بتونه يه مطلبي به من معرفي كنه يا به زبان ساده توضيح بده خيلي خيلي ممنون ميشم

sara.f

شنبه 28 فروردین 1389, 21:23 عصر

سلام
من مي خواستم بدونم اصلا اين نمودار ER چي هست اگه كسي بتونه يه مطلبي به من معرفي كنه يا به زبان ساده توضيح بده خيلي خيلي ممنون ميشم

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

b.i.r.i.y.a

پنج شنبه 02 اردیبهشت 1389, 01:17 صبح

javanerd

پنج شنبه 02 اردیبهشت 1389, 19:45 عصر

چرا اين رابطه many:many تعريف شده ؟
استادمون گفت كه اگه جايي با رابطه ي چند به چند برخورد كرديد احتمال بديد كه يه موجوديت رو فراموش كرديد تعريف كنيد. درسته ؟

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

b.i.r.i.y.a

شنبه 04 اردیبهشت 1389, 02:00 صبح

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

ممنون از جوابت دوست عزيز ولي كاشكي جواب آخرين سوالمو هم ميدادي ...(آيا اين نمودار تاييد شدس ؟)

javanerd

شنبه 04 اردیبهشت 1389, 11:44 صبح

ممنون از جوابت دوست عزيز ولي كاشكي جواب آخرين سوالمو هم ميدادي ...(آيا اين نمودار تاييد شدس ؟)
از نظر من که نه این نمودار و نه قبلی هیچ کدوم مشکلی ندارند.
نظر بقیه رو نمی‌دونم.

sara.f

شنبه 04 اردیبهشت 1389, 12:34 عصر

دوستان اگه ممكنه يه توضيحي درمورد رابطه ي seller و member لطف كنيد. درست متوجه نشدم چي شده.
(آخه همين ترم درس پايگاه داده ها رو گرفتم و تازه كارم)
چرا اين رابطه many:many تعريف شده ؟
استادمون گفت كه اگه جايي با رابطه ي چند به چند برخورد كرديد احتمال بديد كه يه موجوديت رو فراموش كرديد تعريف كنيد. درسته ؟
راستي آخرين نمودار ER اين تاپيك از طرف اساتيد سايت تاييد شده يا هنوز كامل نشده ؟
ممنون از راهنماييتون.

سلام
ببین دوست عزیز، شما تا زمانیکه نرمال سازی را انجام ندادید، ممکنه که رابظه های M~N هم داشته باشید، اما زمانیکه بحث نرمال سازی را انجام دادید، روابط M~N به 1~1 و 1~M شکسته میشند و دیگه نباید از many-to-many خبری باشه.

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

در مورد رابطه Seller , Member هم باید بگم که :

* اگر بخوایم این فرض را در نظر بگیریم که یک فروشنده ، حداقل در ارتباط با یک عضو هست، بنابراین رابطه میشه 1~M

* اگر هم فرض بر این باشد که یک فروشنده، در ارتباط با یک یا چند عضو است و یک عضو هم در ارتباط با یک یا چند فروشنده هست، در اینصورت رابطه میشه N~M

پس Mapping Cardinality ، بستگی به نیازمندیهای شما داره.

در این سیستمی که دوستمون گفتن، فرض بر این بود که یک رابطه M~N بین فروشنده و مشتری برقراره. ( هر چند که به نظر من بهتر بود که این حد را 1~M در نظر بگیریم، به این معنا که یک فروشنده ، حداقل در ارتباط با یک عضو هست و بس. )

sara.f

شنبه 04 اردیبهشت 1389, 12:39 عصر

ممنون از جوابت دوست عزيز ولي كاشكي جواب آخرين سوالمو هم ميدادي ...(آيا اين نمودار تاييد شدس ؟)

یعنی از نظر چه کسی تایید شده هست؟!!!
اینجا هر فردی که دوست داره میاد جواب دوستان را میده.
اگر میخواید بدونید که از نظر من تایید شده هست یا نه، باید بگم که مسلما آره. :چشمک:

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

javanerd

شنبه 04 اردیبهشت 1389, 18:30 عصر

شما تا زمانیکه نرمال سازی را انجام ندادید، ممکنه که رابظه های M~N هم داشته باشید، اما زمانیکه بحث نرمال سازی را انجام دادید، روابط M~N به 1~1 و 1~M شکسته میشند و دیگه نباید از many-to-many خبری باشه.

اگر ممکن هست یکم بیشتر توضیح بدهید.
چون من گیج شدم. من همیشه این تصور رو داشتم که نرمال سازی برای از بین بردن افزونگی انجام میشه. سوالم اینه که حذف شدن این روابط M~N یک نتیجه‌ی جنبی نرمال سازی هست، یا این که یکی از هدف‌های نرمال سازی.

sara.f

یک شنبه 05 اردیبهشت 1389, 02:08 صبح

اگر ممکن هست یکم بیشتر توضیح بدهید.
چون من گیج شدم. من همیشه این تصور رو داشتم که نرمال سازی برای از بین بردن افزونگی انجام میشه. سوالم اینه که حذف شدن این روابط M~N یک نتیجه‌ی جنبی نرمال سازی هست، یا این که یکی از هدف‌های نرمال سازی.

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

javanerd

چهارشنبه 08 اردیبهشت 1389, 07:59 صبح

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

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

روابط M~N هم خودشون باعث redandancy میشن، چون مجبوریم داده هایی را بی رویه تکرار کنیم.
پس اگر نرمال سازی را انجام بدیم، از اونجا که قراره وابستگی های داده ها و روابط را کم کنیم، پس باید رابطه دیگری را تعریف کنیم تا روابط M~N را به 1~M تبدیل کنیم.
در این مورد هم لطفا اگر وقت دارید بیشتر توضیح بدهید (ترجیحا با مثال).