Printable View
سلام
هر کدوم از دوستان که با طراحی نمودار ER اشنایی دارن و میتونن توضیح بدن اینجا لطف کنن راهنمایی کنن که جهت پیاده سازی این نمودار چکار کرد ؟ من موجودیت هامو تشخیص دادم (البته کامل نه )!+ صفت ها + کلید های هر موجودیت ! حالا باید چکار کنم ؟ ارتباطات رو ؟
سلامنقل قول:
نوشته شده توسط majidmir
برای طراحی نمودار ER، اول لازمه که تمام Entity ها را بشناسید.
تمامی Attribute های هر Entity را مشخص کنید، Pk ها را تعیین کنید.
حالا نوبت به طراحی relation ها میرسه.
و همون طور که می دونید، تمامی این مراحل را با توجه به نیازمندیهای نرم افزارتون می تونید انجام بدید.
سلامنقل قول:
نوشته شده توسط sara.f
من تمام موجودیت هام + صفت هاشون رو مخص کردم فقط مشکلم توی ارتباطات هستش کسی میتونه در مورد ارتباطات توضیح بده ؟
برای مثال در یه ویدیو کلوپ رابطه بین فروشنده (Admin ) با فیلم چیه ؟
فروشنده فیلم ها را خریداری میکند
فروشنده ، فیلم را خریداری می کند؟!!!! از کی خریداری می کنه؟نقل قول:
نوشته شده توسط majidmir
مگه در این ویدئو کلوپ، خریدار، فیلم را از فروشنده خریداری نمی کنه؟
مشکل شما احتمالا این هست که به اشتباه فروشنده Admin رو جز موجودیت‌ها به شمار آوردید. در یک ویدیو کلوپ یک فروشنده وجود داره. لازم نیست که این یک تک فروشنده به صورت یک موجودیت مدل بشه. همون طور که لازم نیست خود ویدیو کلوپ به صورت یک موجودیت جدا مدل بشه.نقل قول:
نوشته شده توسط majidmir
اما اگر شما می‌خواهید ویدیوکلوپی رو مدل کنید که توی اون بیشتر از یک فروشنده وجود داره، باز هم رابطه‌ی مستقیمی بین فیلم و فروشنده وجود نداره. اینجا مشکل شما این هست که تمام موجودیت‌ها رو به صورت کامل استخراج نکردید.
شما احتمالا فراموش کردید که به جز موجودیت‌هایی که به صورت فیزیکی وجود دارند ممکنه که یک تعداد موجودیت در مدل ER شما وجود داشته باشه که وجود فیزیکی ندارند و فقط یک مفهوم هستند.
توی مثال شما، به نظر میرسه که فراموش کردید که یک موجودیت به اسم «فروش» یا «فاکتور فروش» یا ... وجود داره که بین موجودیت‌های فروشنده و فیلم قرار میگیره. این موجودیت هم مثل هر موجودیت دیگه یک سری خصوصیت داره، از جمله تاریخ فروش، نوع فروش (نقدی، قسطی) و ...
در صورتی که این موجودیت جدید رو هم در نظر بگیریم، رابطه‌ی بین موجودیت‌ها به شکل زیر هست:
فروشنده یک یا چند فروش انجام می‌دهد -- هر فروش توسط یک فروشنده انجام می‌شود.
هر فروش شامل یک یا چند فیلم است -- هر فیلم در یک فروش به فروش می‌رسد.
البته باز هم توی این مدل یک موجودیت جا افتاده. در واقع باید بین موجودیت‌های «فیلم» و «نسخه‌ی موجود فیلم» تفاوت قایل شد. برای مثال موجودیت فیلم ممکنه برای مدل کردن فیلم «پدرخوانده» استفاده بشه. ولی «نسخه‌ی موجود فیلم» برای مدل کردن ۱۰ عدد سی‌دی یا دی‌وی‌دی که از این فیلم موجوده به کار میره. توجه کنید که همه‌ی این سی‌دی‌ها یا دی‌وی‌دی‌ها فیلم پدر خوانده هستند ولی ممکنه که یکی از سی‌دی‌ها آبی‌رنگ باشه و یکی نقره‌ای. یکی از سی‌دی‌ها توسط شرکت x رایت شده باشه و یکی دیگه توسط شرکت y. یکی از سی‌دی‌ها وضعیت ظاهری خوبی داشته باشه و یکی دیگه خش افتاده باشه. و توی مدل شما هم احتمالا لازم هست که تمام این اطلاعات ذخیره بشوند.
سلام دوست عزیزنقل قول:
نوشته شده توسط javanerd
من فکر نمی کنم در نظر گرفتن یک موجودیت ارتباطی با تعداد آن داشته باشه، یعنی اینجا مهم اینه که موجودیتی به نام فروشنده وجود داره، چه یکی، چه دوتا، .....، چه صدتا.
در مورد این فروش هم، باید بگم که در صورتیکه "فروش" را به صورت یک موجودیت در نظر بگیریم، این سوال به وجود میاد که فروش چی؟ شاید هم عرض شما درست باشه، ولی من اگر باشم، " فروش " را به عنوان یک رابطه در نظر می گرفتم، و نه یک موجودیت. رابطه ای که خودش دارای یک سری خصوصیات هست، از جمله خصوصیاتی که شما گفتید: تاریخ فروش، نوع فروش و ....نقل قول:
نوشته شده توسط javanerd
یعنی بدین صورت : هر فروشنده ، می تواند یک تا چند فیلم را بفروشد.
هر فیلم، توسط یک فروشنده به فروش می رسد.
و در مورد " فاکتور فروش" منم با شما موافقم و باید اون را به عنوان یک موجودیت در نظر گرفت و این خصوصیات را براش در نظر گرفت : تاریخ صدور، شماره فاکتور و....
خیلی خوب می شد که سایر دوستان هم در این مورد نظر خودشون را می گفتند، تا می تونستیم به بهترین طراحی ER برسیم.
سلام
** در مورد موجودیت بودن فروشنده ، من اون رو به عنوان موجودیت در نظر گرفتم اخه در این برنامه ای که قرار بنویسم چند تا فروشنده وجود داره ! فقط الان توی ارتباطش با فیلم مشکل دارم !
من خودم این رو کشیدم حالا شما لطف کنید ایراداتش رو بگید اون جاهایی رو هم که ؟ گذاشتم نمیدونستم باید چی بنویسم تا تکمیل بشه شما لطف کنید مشکلاتش رو به من بگید و اگه میشه تکمیل کنید !
http://www.freeuploadimages.org/imag...55ide59xsv.jpg
دوست عزیز من هنوز متوجه نشدم، این فروشنده شما فیلم را از کجا میخره؟نقل قول:
نوشته شده توسط majidmir
نکته دیگه اینکه در این ویدئو کلوپ شما قانونی وجود داره که فقط فیلم را کرایه می کنن؟
یا اینکه مشتری ها می تونند فیلم را خریداری هم بکنند؟
شما باید تمام نیازمندیها، اعم از شرایط پروژه را ذکر کنید، تا بشه یه ER جامع را طراحی کرد.
سلامنقل قول:
نوشته شده توسط sara.f
این فروشنده فقط کار کرایه دادن فیلم رو انجام میده ! به هر حال این فیلم از یه جایی خریداری میشه و یه سری صفت داره مثل تاریخ خرید فیلم قیمت خرید و ..... که اینا رو فعلا ذکر نکردم ! ولی باید ذکر بشه !
نیازمندی ها :
خرید فیلم
کرایه دادن فیلم
عضویت مشتریان
محرومیت کاربران
کاملا با شما موافقم.نقل قول:
نوشته شده توسط sara.f
دلیل اینکه من بین یک رابطه و یک موجودیت تفاوتی قایل نشدم این بود که در نهایت همه‌ی این موجودیت‌ها و رابطه‌ها به صورت یک جدول در پایگاه داده یا یک کلاس در کد برنامه ظاهر می‌شوند.
سلام
من باید حتما سه تا موجودیت قوی داشته باشم حالا به نظر شما باید چکار کنم ؟
من داشتم این طوری فکر می‌کردم.
کاملا با شما موافقم. در نظر گرفتن یک موجودیت ارتباطی با تعدادش نداره. بلکه چیزی که مشخص می‌کنه که یک موجودیت باید در یک ER گنجانده بشه یا نه این موضوع هست که اطلاعات این موجودیت قرار هست در برنامه ذخیره و استفاده بشه یا نه.نقل قول:
نوشته شده توسط sara.f
اجازه بدهید که منظورم رو بهتر توضیح بدهم تا باعث سردرگمی بقیه هم نشه.
توی یک ویدیو کلوپ موجودیت‌های زیاد دیگه‌ای وجود داره ولی فقط اونهایی باید مدل بشوند که قراره اطلاعاتشون در برنامه استفاده بشه. منظور من این بود که اگر در این ویدیوکلوپ فقط یک فروشنده وجود داره در این صورت احتمالا ما نیازی نداریم که اطلاعات مربوط به اون یک نفر رو ذخیره کنیم. همون طور که نیاز نداریم اطلاعات مربوط به خود ویدیو کلوپ مثل آدرس ویدیو کلوپ رو ذخیره کنیم. البته بهتر بود به جای ذخیره از یک واژه‌ی دیگه استفاده می کردم مثلا manipulate. چون اطلاعات فروشنده ممکنه یه جایی ذخیره بشوند ولی احتمالا نیازی نیست که توی پایگاه‌داده ذخیره بشوند و تا آخر عمر نرم‌افزار هم هیچ وقت تغییر نمی‌کنند.
سلام
دوستان بهتر نیست یه جمع بندی کلی بزنید و نمودار رو تکمیل کنیم ؟
بسیار خوب.نقل قول:
نوشته شده توسط majidmir
پس موجودیت هایی که از خارح از ویدئو کلوپ با این سیستم تعامل دارند هم برای شما مهم هست.
یعنی نیاز هست که موجودیت دیگری را هم به عنوان عمده فروش در نظر بگیریم که فیلم ها را به این ویدئو کلوپ می فروشه.
با این توضیحاتی که دادید ، حالا میشه تا حدودی نمودار را رسم کرد.
درسته، ولی در صورتی که قرار باشه خصوصیات یک فروشنده تغییر کنه، پس نیاز به data manipulation هم احساس میشه و در این مورد هم بهتر هست که فروشنده به عنوان یک موجودیت ذکر بشه.نقل قول:
نوشته شده توسط javanerd
عجله نکنید، چون تا زمانیکه تمامی نیازمندیها را استخراج نکنید، نمی تونید نمودار درست و جامعی را طراحی کنید. برای شروع من این نمودار رسم کردم،( با توجه به دریافتهای خودم از نیازمندیهایی که ارائه دادید) هر جایی از این نمودار را که فکر می کنید مطابق با سیستم مورد نظر شما نیست ، بگید.نقل قول:
نوشته شده توسط majidmir
ضمیمه 46793
سلام
به نظر من اینجوری بهتره چون نیازی به موجودیت عمده فروش نیست
فقط این قسمت رو که قرمز کردم روی ارتباطاتش باید توجه بشه اگه ما ID,NAME یه کاربر رو ثبت کنیم پس رابطه باید M باشه نه 1 (به نظر من !)
برای اینکه اعضا بتونند فیلم‌ها رو کرایه کنند به یک رابطه بین member و movie نیاز داریم.نقل قول:
نوشته شده توسط sara.f
فک کنم این رابطه توسط فروشنده برقرار میشه و نیازی به رابطه مستقیم نیست :متفکر:نقل قول:
نوشته شده توسط javanerd
آره آره درسته، فراموش کردم این رابطه را در این شکله بکشم.نقل قول:
نوشته شده توسط javanerd
اصلش اینطوریه.
اگر بخواهیم اینطور فکر کنیم که تمام روابط توسط خدواند قادر متعال برقرار می‌شوند و نیازی به هیچ رابطه‌ی مستقیمی نیست.:قهقهه:نقل قول:
نوشته شده توسط majidmir
شوخی کردم. به این رابطه نیاز هست چون ما می‌خواهیم در مورد این رابطه یک سری داده ذخیره کنیم (مثل تاریخ اجاره کردن و تاریخ برگشت و ...)
لطفا بقیه نظر بدهند.
به صورت غیر مستقیم نمیشه رابطه رو ایجاد کرد ؟نقل قول:
نوشته شده توسط sara.f
من منظور شما را متوجه نمی شم دوست عزیز.نقل قول:
نوشته شده توسط majidmir
این اعدادی که نوشتم کاری به خصوصیات موجودیتمون نداره، این رابطه 1~M که نوشتم معنیش اینه که هر فروشنده می تواند چندین عضو را بپذیرد یا محروم کند.
منظورتون از غیر مستقیم چیه؟ و کدوم رابطه را می گید؟نقل قول:
نوشته شده توسط majidmir
وقتی که شما واسه فروشنده یه ID , NAME رو در نظر میگیرید یعنی چند فروشنده پس رابطه ما M~N میشه نه 1~Mنقل قول:
نوشته شده توسط sara.f
منظورم اینه که میشه فروشنده رو به عنوان یه رابط بین فیلم و عضو در نظر گرفت ؟ و توی رابطه عضو و مشتری تاریخ کرایه و مجوز ها رو ذخیره کنیم یعنی در واقع فقط از یه جدول رابطه ای استفاده کنیم ؟نقل قول:
نوشته شده توسط sara.f
اگه فقط من سه موجودیت عضو - فروشنده- فیلم رو در نظر بگیرم نه بیشتر نمودارم چطوری میشه ؟
نظر خودم روی این نموداره به نظرتون مشکلی داره یا نه ؟
من بازم می گم که به نظر من ، ثبت خصوصیات یک موجودیت در DB ، دلیلی بر این نیست که تعداد این موجودیت بیشتر از یکی هست.نقل قول:
نوشته شده توسط majidmir
یعنی شما نمی تونید بگید چون مشخصات فروشنده ثبت میشه، یعنی حتما بیشتر از یک نفر هست. اگر من اشتباه می کنم، دوستان لطف کنند تصحیح کنند.
اما اگر خودتون فرض را بر این گذاشتید که تعداد فروشنده بیشتر از یکی هست، بله در اینصورت رابطه را می تونید به M~N تغییر بدید.
اول اینکه منظورتون از رابطه عضو و مشتری چیه؟!!!نقل قول:
منظورم اینه که میشه فروشنده رو به عنوان یه رابط بین فیلم و عضو در نظر گرفت ؟ و توی رابطه عضو و مشتری تاریخ کرایه و مجوز ها رو ذخیره کنیم یعنی در واقع فقط از یه جدول رابطه ای استفاده کنیم ؟
دوم اینکه رابط بودن فروشنده در این سیستم از نظر من بی معنیه، یعنی اینکه دو موجودیت مشتری( عضو) و فروشنده ، هر دو در اینجا Primary Actor هستند و رابطه مستقیم با ویدئو کلوپ دارند و وساطت این وسط معنی نداره.
من این نمودار ER را بر اساس نیازمندیهایی که شما گفتید رسم کردم و شما هم گفته بودید که فروشنده بالاخره باید فیلم را از یه جایی بخره، بنابر این من اون رابطه Sell/Buy را در نظر گرفتم.نقل قول:
[COLOR=Blue]اگه فقط من سه موجودیت عضو - فروشنده- فیلم رو در نظر بگیرم نه بیشتر نمودارم چطوری میشه ؟
نظر خودم روی این نموداره به نظرتون مشکلی داره یا نه ؟
اگر از نظر شما نیازی نیست که در رابطه با خریده شدن فیلم صحبتی بشه ، پس می تونید اون قسمت را حذف کنید.
یعنی نمودار میشه این. ( ولی توجه داشته باشید که اگر استادتون گفته : سه موجودیت قوی باید داشته باشید ، بدین معنی نیست که حتما و فقط باید سه موجودیت داشته باشید.)
پیروز باشی.
سلام
من مي خواستم بدونم اصلا اين نمودار ER چي هست اگه كسي بتونه يه مطلبي به من معرفي كنه يا به زبان ساده توضيح بده خيلي خيلي ممنون ميشم
سلامنقل قول:
نوشته شده توسط AZERILA
شما می تونید برای این سوالتون در سایت جستجو کنید و اگر مطلب مورد نظرتون را پیدا نکردید، سوالتون را در تاپیک جداگانه ای مطرح کنید تا بتونیم کمکتون کنیم.
دوستان اگه ممكنه يه توضيحي درمورد رابطه ي seller و member لطف كنيد. درست متوجه نشدم چي شده.
(آخه همين ترم درس پايگاه داده ها رو گرفتم و تازه كارم)
چرا اين رابطه many:many تعريف شده ؟
استادمون گفت كه اگه جايي با رابطه ي چند به چند برخورد كرديد احتمال بديد كه يه موجوديت رو فراموش كرديد تعريف كنيد. درسته ؟
راستي آخرين نمودار ER اين تاپيك از طرف اساتيد سايت تاييد شده يا هنوز كامل نشده ؟
ممنون از راهنماييتون.
وقتی بین دوتا از موجودیت‌ها یک رابطه‌ی چند به چند وجود داره حتی اگر هیچ موجودیتی رو هم فراموش نکرده باشید، موقع ساختن جدول‌ها توی پایگاه داده لازم هست که یک جدول اضافه درست کنید و از طریق این جدول این دو تا موجودیت رو به هم ربط بدهید. شاید خیلی وقت‌ها این جدول خودش دارای معنا باشه و بشه به عنوان یک موجودیت جدید بهش نگاه کرد.نقل قول:
نوشته شده توسط b.i.r.i.y.a
در ضمن این نکته رو هم فراموش نکنید که رابطه‌ها هم در حقیقت یک جور موجودیت (خاص) هستند.
ممنون از جوابت دوست عزيز ولي كاشكي جواب آخرين سوالمو هم ميدادي ...(آيا اين نمودار تاييد شدس ؟)نقل قول:
نوشته شده توسط javanerd
از نظر من که نه این نمودار و نه قبلی هیچ کدوم مشکلی ندارند.نقل قول:
نوشته شده توسط b.i.r.i.y.a
نظر بقیه رو نمی‌دونم.
سلامنقل قول:
نوشته شده توسط b.i.r.i.y.a
ببین دوست عزیز، شما تا زمانیکه نرمال سازی را انجام ندادید، ممکنه که رابظه های M~N هم داشته باشید، اما زمانیکه بحث نرمال سازی را انجام دادید، روابط M~N به 1~1 و 1~M شکسته میشند و دیگه نباید از many-to-many خبری باشه.
---------------------------------------------------------
در مورد رابطه Seller , Member هم باید بگم که :
* اگر بخوایم این فرض را در نظر بگیریم که یک فروشنده ، حداقل در ارتباط با یک عضو هست، بنابراین رابطه میشه 1~M
* اگر هم فرض بر این باشد که یک فروشنده، در ارتباط با یک یا چند عضو است و یک عضو هم در ارتباط با یک یا چند فروشنده هست، در اینصورت رابطه میشه N~M
پس Mapping Cardinality ، بستگی به نیازمندیهای شما داره.
در این سیستمی که دوستمون گفتن، فرض بر این بود که یک رابطه M~N بین فروشنده و مشتری برقراره. ( هر چند که به نظر من بهتر بود که این حد را 1~M در نظر بگیریم، به این معنا که یک فروشنده ، حداقل در ارتباط با یک عضو هست و بس. )
یعنی از نظر چه کسی تایید شده هست؟!!!نقل قول:
نوشته شده توسط b.i.r.i.y.a
اینجا هر فردی که دوست داره میاد جواب دوستان را میده.
اگر میخواید بدونید که از نظر من تایید شده هست یا نه، باید بگم که مسلما آره. :چشمک:
اگر سایر دوستان نظری دارن،مبنی براینکه جایی از نمودار اشکال داره، خوشحال میشیم اگه بگن، تا حداقل ما هم یه چیزکی یاد بگیریم.
اگر ممکن هست یکم بیشتر توضیح بدهید.نقل قول:
نوشته شده توسط sara.f
چون من گیج شدم. من همیشه این تصور رو داشتم که نرمال سازی برای از بین بردن افزونگی انجام میشه. سوالم اینه که حذف شدن این روابط M~N یک نتیجه‌ی جنبی نرمال سازی هست، یا این که یکی از هدف‌های نرمال سازی.
تا اونجا که من اطلاع دارم، اگر نرمال سازی به درستی انجام بشه، در این صورت وابستگی های رابطه ای از بین میرن و دیگه redandancy نخواهیم داشت. ( البته به صفر نمیرسه)نقل قول:
نوشته شده توسط javanerd
روابط M~N هم خودشون باعث redandancy میشن، چون مجبوریم داده هایی را بی رویه تکرار کنیم.
پس اگر نرمال سازی را انجام بدیم، از اونجا که قراره وابستگی های داده ها و روابط را کم کنیم، پس باید رابطه دیگری را تعریف کنیم تا روابط M~N را به 1~M تبدیل کنیم.
فکر نمی‌کنم که با نرمال‌سازی وابستگی‌های رابطه‌ای از بین بروند. ولی موافقم که همیشه نمیشه افزونگی رو به صفر رسوند.نقل قول:
نوشته شده توسط sara.f
در این مورد هم لطفا اگر وقت دارید بیشتر توضیح بدهید (ترجیحا با مثال).نقل قول:
نوشته شده توسط sara.f
سلام دوستان لطف میکنید فایل آماده جداول رو در sql قرار بدید برای دانلود.
لطفا روابط بین موجودیت ها رو هم بکشید.
من اصلا بلد نیستم تو SQL Server Management Studio کار کنم.لطفا کمک کنید.ممنون.
سلام دوستان لطف میکنید فایل آماده جداول رو در sql قرار بدید برای دانلود.
لطفا روابط بین موجودیت ها رو هم بکشید.
من اصلا بلد نیستم تو SQL Server Management Studio کار کنم.لطفا کمک کنید.ممنون.
برای همین پروژه ویدئو کلوپ میخوام.