آموزش طراحی نمودار ER ?
سلام
هر کدوم از دوستان که با طراحی نمودار ER اشنایی دارن و میتونن توضیح بدن اینجا لطف کنن راهنمایی کنن که جهت پیاده سازی این نمودار چکار کرد ؟ من موجودیت هامو تشخیص دادم (البته کامل نه )!+ صفت ها + کلید های هر موجودیت ! حالا باید چکار کنم ؟ ارتباطات رو ؟
سلامنوشته شده توسط majidmir
برای طراحی نمودار ER، اول لازمه که تمام Entity ها را بشناسید.
تمامی Attribute های هر Entity را مشخص کنید، Pk ها را تعیین کنید.
حالا نوبت به طراحی relation ها میرسه.
و همون طور که می دونید، تمامی این مراحل را با توجه به نیازمندیهای نرم افزارتون می تونید انجام بدید.
سلام
من تمام موجودیت هام + صفت هاشون رو مخص کردم فقط مشکلم توی ارتباطات هستش کسی میتونه در مورد ارتباطات توضیح بده ؟
برای مثال در یه ویدیو کلوپ رابطه بین فروشنده (Admin ) با فیلم چیه ؟
فروشنده فیلم ها را خریداری میکند
فروشنده ، فیلم را خریداری می کند؟!!!! از کی خریداری می کنه؟
مگه در این ویدئو کلوپ، خریدار، فیلم را از فروشنده خریداری نمی کنه؟
مشکل شما احتمالا این هست که به اشتباه فروشنده Admin رو جز موجودیت‌ها به شمار آوردید. در یک ویدیو کلوپ یک فروشنده وجود داره. لازم نیست که این یک تک فروشنده به صورت یک موجودیت مدل بشه. همون طور که لازم نیست خود ویدیو کلوپ به صورت یک موجودیت جدا مدل بشه.
اما اگر شما می‌خواهید ویدیوکلوپی رو مدل کنید که توی اون بیشتر از یک فروشنده وجود داره، باز هم رابطه‌ی مستقیمی بین فیلم و فروشنده وجود نداره. اینجا مشکل شما این هست که تمام موجودیت‌ها رو به صورت کامل استخراج نکردید.
شما احتمالا فراموش کردید که به جز موجودیت‌هایی که به صورت فیزیکی وجود دارند ممکنه که یک تعداد موجودیت در مدل ER شما وجود داشته باشه که وجود فیزیکی ندارند و فقط یک مفهوم هستند.
توی مثال شما، به نظر میرسه که فراموش کردید که یک موجودیت به اسم «فروش» یا «فاکتور فروش» یا ... وجود داره که بین موجودیت‌های فروشنده و فیلم قرار میگیره. این موجودیت هم مثل هر موجودیت دیگه یک سری خصوصیت داره، از جمله تاریخ فروش، نوع فروش (نقدی، قسطی) و ...
در صورتی که این موجودیت جدید رو هم در نظر بگیریم، رابطه‌ی بین موجودیت‌ها به شکل زیر هست:
فروشنده یک یا چند فروش انجام می‌دهد -- هر فروش توسط یک فروشنده انجام می‌شود.
هر فروش شامل یک یا چند فیلم است -- هر فیلم در یک فروش به فروش می‌رسد.
البته باز هم توی این مدل یک موجودیت جا افتاده. در واقع باید بین موجودیت‌های «فیلم» و «نسخه‌ی موجود فیلم» تفاوت قایل شد. برای مثال موجودیت فیلم ممکنه برای مدل کردن فیلم «پدرخوانده» استفاده بشه. ولی «نسخه‌ی موجود فیلم» برای مدل کردن ۱۰ عدد سی‌دی یا دی‌وی‌دی که از این فیلم موجوده به کار میره. توجه کنید که همه‌ی این سی‌دی‌ها یا دی‌وی‌دی‌ها فیلم پدر خوانده هستند ولی ممکنه که یکی از سی‌دی‌ها آبی‌رنگ باشه و یکی نقره‌ای. یکی از سی‌دی‌ها توسط شرکت x رایت شده باشه و یکی دیگه توسط شرکت y. یکی از سی‌دی‌ها وضعیت ظاهری خوبی داشته باشه و یکی دیگه خش افتاده باشه. و توی مدل شما هم احتمالا لازم هست که تمام این اطلاعات ذخیره بشوند.
سلام دوست عزیز
من فکر نمی کنم در نظر گرفتن یک موجودیت ارتباطی با تعداد آن داشته باشه، یعنی اینجا مهم اینه که موجودیتی به نام فروشنده وجود داره، چه یکی، چه دوتا، .....، چه صدتا.
در مورد این فروش هم، باید بگم که در صورتیکه "فروش" را به صورت یک موجودیت در نظر بگیریم، این سوال به وجود میاد که فروش چی؟ شاید هم عرض شما درست باشه، ولی من اگر باشم، " فروش " را به عنوان یک رابطه در نظر می گرفتم، و نه یک موجودیت. رابطه ای که خودش دارای یک سری خصوصیات هست، از جمله خصوصیاتی که شما گفتید: تاریخ فروش، نوع فروش و ....
یعنی بدین صورت : هر فروشنده ، می تواند یک تا چند فیلم را بفروشد.
هر فیلم، توسط یک فروشنده به فروش می رسد.
و در مورد " فاکتور فروش" منم با شما موافقم و باید اون را به عنوان یک موجودیت در نظر گرفت و این خصوصیات را براش در نظر گرفت : تاریخ صدور، شماره فاکتور و....
خیلی خوب می شد که سایر دوستان هم در این مورد نظر خودشون را می گفتند، تا می تونستیم به بهترین طراحی ER برسیم.
سلام
** در مورد موجودیت بودن فروشنده ، من اون رو به عنوان موجودیت در نظر گرفتم اخه در این برنامه ای که قرار بنویسم چند تا فروشنده وجود داره ! فقط الان توی ارتباطش با فیلم مشکل دارم !
من خودم این رو کشیدم حالا شما لطف کنید ایراداتش رو بگید اون جاهایی رو هم که ؟ گذاشتم نمیدونستم باید چی بنویسم تا تکمیل بشه شما لطف کنید مشکلاتش رو به من بگید و اگه میشه تکمیل کنید !
دوست عزیز من هنوز متوجه نشدم، این فروشنده شما فیلم را از کجا میخره؟سلام
** در مورد موجودیت بودن فروشنده ، من اون رو به عنوان موجودیت در نظر گرفتم اخه در این برنامه ای که قرار بنویسم چند تا فروشنده وجود داره ! فقط الان توی ارتباطش با فیلم مشکل دارم !
من خودم این رو کشیدم حالا شما لطف کنید ایراداتش رو بگید اون جاهایی رو هم که ؟ گذاشتم نمیدونستم باید چی بنویسم تا تکمیل بشه شما لطف کنید مشکلاتش رو به من بگید و اگه میشه تکمیل کنید !
نکته دیگه اینکه در این ویدئو کلوپ شما قانونی وجود داره که فقط فیلم را کرایه می کنن؟
یا اینکه مشتری ها می تونند فیلم را خریداری هم بکنند؟
شما باید تمام نیازمندیها، اعم از شرایط پروژه را ذکر کنید، تا بشه یه ER جامع را طراحی کرد.
سلام
این فروشنده فقط کار کرایه دادن فیلم رو انجام میده ! به هر حال این فیلم از یه جایی خریداری میشه و یه سری صفت داره مثل تاریخ خرید فیلم قیمت خرید و ..... که اینا رو فعلا ذکر نکردم ! ولی باید ذکر بشه !
نیازمندی ها :
خرید فیلم
کرایه دادن فیلم
عضویت مشتریان
محرومیت کاربران
کاملا با شما موافقم.
دلیل اینکه من بین یک رابطه و یک موجودیت تفاوتی قایل نشدم این بود که در نهایت همه‌ی این موجودیت‌ها و رابطه‌ها به صورت یک جدول در پایگاه داده یا یک کلاس در کد برنامه ظاهر می‌شوند.
آخرین ویرایش به وسیله javanerd : پنج شنبه 19 فروردین 1389 در 19:34 عصر
سلام
من باید حتما سه تا موجودیت قوی داشته باشم حالا به نظر شما باید چکار کنم ؟
من داشتم این طوری فکر می‌کردم.
کاملا با شما موافقم. در نظر گرفتن یک موجودیت ارتباطی با تعدادش نداره. بلکه چیزی که مشخص می‌کنه که یک موجودیت باید در یک ER گنجانده بشه یا نه این موضوع هست که اطلاعات این موجودیت قرار هست در برنامه ذخیره و استفاده بشه یا نه.
اجازه بدهید که منظورم رو بهتر توضیح بدهم تا باعث سردرگمی بقیه هم نشه.
توی یک ویدیو کلوپ موجودیت‌های زیاد دیگه‌ای وجود داره ولی فقط اونهایی باید مدل بشوند که قراره اطلاعاتشون در برنامه استفاده بشه. منظور من این بود که اگر در این ویدیوکلوپ فقط یک فروشنده وجود داره در این صورت احتمالا ما نیازی نداریم که اطلاعات مربوط به اون یک نفر رو ذخیره کنیم. همون طور که نیاز نداریم اطلاعات مربوط به خود ویدیو کلوپ مثل آدرس ویدیو کلوپ رو ذخیره کنیم. البته بهتر بود به جای ذخیره از یک واژه‌ی دیگه استفاده می کردم مثلا manipulate. چون اطلاعات فروشنده ممکنه یه جایی ذخیره بشوند ولی احتمالا نیازی نیست که توی پایگاه‌داده ذخیره بشوند و تا آخر عمر نرم‌افزار هم هیچ وقت تغییر نمی‌کنند.
سلام
دوستان بهتر نیست یه جمع بندی کلی بزنید و نمودار رو تکمیل کنیم ؟
بسیار خوب.
پس موجودیت هایی که از خارح از ویدئو کلوپ با این سیستم تعامل دارند هم برای شما مهم هست.
یعنی نیاز هست که موجودیت دیگری را هم به عنوان عمده فروش در نظر بگیریم که فیلم ها را به این ویدئو کلوپ می فروشه.
با این توضیحاتی که دادید ، حالا میشه تا حدودی نمودار را رسم کرد.
درسته، ولی در صورتی که قرار باشه خصوصیات یک فروشنده تغییر کنه، پس نیاز به data manipulation هم احساس میشه و در این مورد هم بهتر هست که فروشنده به عنوان یک موجودیت ذکر بشه.
عجله نکنید، چون تا زمانیکه تمامی نیازمندیها را استخراج نکنید، نمی تونید نمودار درست و جامعی را طراحی کنید. برای شروع من این نمودار رسم کردم،( با توجه به دریافتهای خودم از نیازمندیهایی که ارائه دادید) هر جایی از این نمودار را که فکر می کنید مطابق با سیستم مورد نظر شما نیست ، بگید.
سلام
به نظر من اینجوری بهتره چون نیازی به موجودیت عمده فروش نیست
فقط این قسمت رو که قرمز کردم روی ارتباطاتش باید توجه بشه اگه ما ID,NAME یه کاربر رو ثبت کنیم پس رابطه باید M باشه نه 1 (به نظر من !)
برای اینکه اعضا بتونند فیلم‌ها رو کرایه کنند به یک رابطه بین member و movie نیاز داریم.هر جایی از این نمودار را که فکر می کنید مطابق با سیستم مورد نظر شما نیست ، بگید.
فک کنم این رابطه توسط فروشنده برقرار میشه و نیازی به رابطه مستقیم نیست
آره آره درسته، فراموش کردم این رابطه را در این شکله بکشم.
اصلش اینطوریه.
اگر بخواهیم اینطور فکر کنیم که تمام روابط توسط خدواند قادر متعال برقرار می‌شوند و نیازی به هیچ رابطه‌ی مستقیمی نیست.فک کنم این رابطه توسط فروشنده برقرار میشه و نیازی به رابطه مستقیم نیست
شوخی کردم. به این رابطه نیاز هست چون ما می‌خواهیم در مورد این رابطه یک سری داده ذخیره کنیم (مثل تاریخ اجاره کردن و تاریخ برگشت و ...)
لطفا بقیه نظر بدهند.
به صورت غیر مستقیم نمیشه رابطه رو ایجاد کرد ؟آره آره درسته، فراموش کردم این رابطه را در این شکله بکشم.
اصلش اینطوریه.
من منظور شما را متوجه نمی شم دوست عزیز.
این اعدادی که نوشتم کاری به خصوصیات موجودیتمون نداره، این رابطه 1~M که نوشتم معنیش اینه که هر فروشنده می تواند چندین عضو را بپذیرد یا محروم کند.
منظورتون از غیر مستقیم چیه؟ و کدوم رابطه را می گید؟
وقتی که شما واسه فروشنده یه ID , NAME رو در نظر میگیرید یعنی چند فروشنده پس رابطه ما M~N میشه نه 1~M
منظورم اینه که میشه فروشنده رو به عنوان یه رابط بین فیلم و عضو در نظر گرفت ؟ و توی رابطه عضو و مشتری تاریخ کرایه و مجوز ها رو ذخیره کنیم یعنی در واقع فقط از یه جدول رابطه ای استفاده کنیم ؟
اگه فقط من سه موجودیت عضو - فروشنده- فیلم رو در نظر بگیرم نه بیشتر نمودارم چطوری میشه ؟
نظر خودم روی این نموداره به نظرتون مشکلی داره یا نه ؟
آخرین ویرایش به وسیله majidmir : شنبه 21 فروردین 1389 در 12:01 عصر
من بازم می گم که به نظر من ، ثبت خصوصیات یک موجودیت در DB ، دلیلی بر این نیست که تعداد این موجودیت بیشتر از یکی هست.
یعنی شما نمی تونید بگید چون مشخصات فروشنده ثبت میشه، یعنی حتما بیشتر از یک نفر هست. اگر من اشتباه می کنم، دوستان لطف کنند تصحیح کنند.
اما اگر خودتون فرض را بر این گذاشتید که تعداد فروشنده بیشتر از یکی هست، بله در اینصورت رابطه را می تونید به M~N تغییر بدید.
اول اینکه منظورتون از رابطه عضو و مشتری چیه؟!!!منظورم اینه که میشه فروشنده رو به عنوان یه رابط بین فیلم و عضو در نظر گرفت ؟ و توی رابطه عضو و مشتری تاریخ کرایه و مجوز ها رو ذخیره کنیم یعنی در واقع فقط از یه جدول رابطه ای استفاده کنیم ؟
دوم اینکه رابط بودن فروشنده در این سیستم از نظر من بی معنیه، یعنی اینکه دو موجودیت مشتری( عضو) و فروشنده ، هر دو در اینجا Primary Actor هستند و رابطه مستقیم با ویدئو کلوپ دارند و وساطت این وسط معنی نداره.
من این نمودار ER را بر اساس نیازمندیهایی که شما گفتید رسم کردم و شما هم گفته بودید که فروشنده بالاخره باید فیلم را از یه جایی بخره، بنابر این من اون رابطه Sell/Buy را در نظر گرفتم.[COLOR=Blue]اگه فقط من سه موجودیت عضو - فروشنده- فیلم رو در نظر بگیرم نه بیشتر نمودارم چطوری میشه ؟
نظر خودم روی این نموداره به نظرتون مشکلی داره یا نه ؟
اگر از نظر شما نیازی نیست که در رابطه با خریده شدن فیلم صحبتی بشه ، پس می تونید اون قسمت را حذف کنید.
یعنی نمودار میشه این. ( ولی توجه داشته باشید که اگر استادتون گفته : سه موجودیت قوی باید داشته باشید ، بدین معنی نیست که حتما و فقط باید سه موجودیت داشته باشید.)
پیروز باشی.
آخرین ویرایش به وسیله sara.f : شنبه 04 اردیبهشت 1389 در 12:19 عصر
سلام
من مي خواستم بدونم اصلا اين نمودار ER چي هست اگه كسي بتونه يه مطلبي به من معرفي كنه يا به زبان ساده توضيح بده خيلي خيلي ممنون ميشم
سلام
شما می تونید برای این سوالتون در سایت جستجو کنید و اگر مطلب مورد نظرتون را پیدا نکردید، سوالتون را در تاپیک جداگانه ای مطرح کنید تا بتونیم کمکتون کنیم.
دوستان اگه ممكنه يه توضيحي درمورد رابطه ي 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 در نظر بگیریم، به این معنا که یک فروشنده ، حداقل در ارتباط با یک عضو هست و بس. )
یعنی از نظر چه کسی تایید شده هست؟!!!
اینجا هر فردی که دوست داره میاد جواب دوستان را میده.
اگر میخواید بدونید که از نظر من تایید شده هست یا نه، باید بگم که مسلما آره.
اگر سایر دوستان نظری دارن،مبنی براینکه جایی از نمودار اشکال داره، خوشحال میشیم اگه بگن، تا حداقل ما هم یه چیزکی یاد بگیریم.
اگر ممکن هست یکم بیشتر توضیح بدهید.
چون من گیج شدم. من همیشه این تصور رو داشتم که نرمال سازی برای از بین بردن افزونگی انجام میشه. سوالم اینه که حذف شدن این روابط M~N یک نتیجه‌ی جنبی نرمال سازی هست، یا این که یکی از هدف‌های نرمال سازی.
تا اونجا که من اطلاع دارم، اگر نرمال سازی به درستی انجام بشه، در این صورت وابستگی های رابطه ای از بین میرن و دیگه redandancy نخواهیم داشت. ( البته به صفر نمیرسه)
روابط M~N هم خودشون باعث redandancy میشن، چون مجبوریم داده هایی را بی رویه تکرار کنیم.
پس اگر نرمال سازی را انجام بدیم، از اونجا که قراره وابستگی های داده ها و روابط را کم کنیم، پس باید رابطه دیگری را تعریف کنیم تا روابط M~N را به 1~M تبدیل کنیم.
فکر نمی‌کنم که با نرمال‌سازی وابستگی‌های رابطه‌ای از بین بروند. ولی موافقم که همیشه نمیشه افزونگی رو به صفر رسوند.
در این مورد هم لطفا اگر وقت دارید بیشتر توضیح بدهید (ترجیحا با مثال).
سلام دوستان لطف میکنید فایل آماده جداول رو در sql قرار بدید برای دانلود.
لطفا روابط بین موجودیت ها رو هم بکشید.
من اصلا بلد نیستم تو SQL Server Management Studio کار کنم.لطفا کمک کنید.ممنون.
سلام دوستان لطف میکنید فایل آماده جداول رو در sql قرار بدید برای دانلود.
لطفا روابط بین موجودیت ها رو هم بکشید.
من اصلا بلد نیستم تو SQL Server Management Studio کار کنم.لطفا کمک کنید.ممنون.
برای همین پروژه ویدئو کلوپ میخوام.
پاسخ با نقل قول
