ارتباط بین فاکتور- مشتری- جنس- پیک

[mf_007]

اگر می شه توی طراحی این er کمکم کنید

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

مشتری 1 <سفارش می دهد> اجناس n

فاکتور n <صادر می شود برای> مشتری 1

اجناس n <قرار می گیرد > در فاکتور n

تا اینجاش رو نمی دونم درسته یا نه اگه غلطه راهنمایی کنید

و ارتباط بین مشتری و پیک
مشتری و فاکتور
پیک و فاکتور رو چهطوری پیاده سازی کنم؟

و در این سیستم منظور از مشتری همون مشتری تلفنیه چون اطلاعات مشتری حضوری ثبت نمی شود

[taghvajou]

سلام به همه
بین مشتری و پیک نباید رابطه ای وجود داشته باشه. پیک با مشتری کاری نداره! دقت کنین!
این پیک با سفارش (فاکتور) کار داره یک رابطه یک به یک. هر سفارش توسط یک پیک به دست مشتری میرسه! ( نگاهتو عوض کن)

مشتری میتونه چند سفارش (فاکتور) داشته باشه! پس یه رابطه یک به چند بین مشتری و فاکتور وجود داره

اگه کافی نبود مفصل بحث کنیم.

[mf_007]

پس ارتباط بین فاکتور و مشتری که نوشتم درسته؟

ارتباط بین پیک و فاکتور 1به 1 می شه یا 1 به n؟

یک پیک می تونه n تا فاکتور(سفارش) رو به مشتری تحویل بده و یک فاکتور توسط یک پیک به مشتری تحویل داده می شه؟
1 به 1 یا 1 به n می شه؟

[taghvajou]

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

[mf_007]

نمی تونیم اینطوری بگیم که

یک پیک می تونه چند سفارش(فاکتور ) رو تحویل بده؟ پس می شه 1 به n ؟

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

[majidmir]

اگر می شه توی طراحی این er کمکم کنید

و در این سیستم منظور از مشتری همون مشتری تلفنیه چون اطلاعات مشتری حضوری ثبت نمی شود

سلام
دوست عزيز به نظر من فاكتور جز موجوديت ها نيست .
اگر حضوری خرید کنه


در صورت درخواست فاکتور صادر می شه براش

به نظر من اين اشتباهه كه صدور صورتحساب بدست مشتري باشه ! در هر صورت اين صورتحساب بايد صادر بشه براي عملياتي كه قراره انجام بدي مثلا اينكه در طول روز چقدر فروش كردي و چي بوده !

مشتری 1 <سفارش می دهد> اجناس n
اين رابطه M به N هست
هر مشتري سفارش ميدهد چند جنس را !
هر جنس داده ميشود به چند مشتري !
مثال
مشتري جنس
A 111
B 222
C 333
D 444
مشتري 111 جنس A,B,C را سفارش ميدهد
جنس A به مشتري 111و222و444 داده مي شود !
(من اينو اينجوري اناليز كردم حالا درست و غلطش رو بزرگان توضيح بدن )!


فاکتور n <صادر می شود برای> مشتری 1

اين رابطه 1 به 1 هست چون براي هر مشتري فقط يك فاكتور صادر ميشود و هر فاكتور متعلق به يك مشتري است)‌

اجناس n <قرار می گیرد > در فاکتور n
اين رابطه هم از نوع M به N هست ولي اصلا چرا اين رابطه رو گذاشتي ؟‌

و ارتباط بین مشتری و پیک
اگه هر پيك فقط بتواند براي يك مشتري جنس ببرد در اينصورت رابطه به صورت 1 به 1 هست
پيك A براي مشتري 111 جنس ميبرد !
پيك B‌براي مشتري 222 جنس ميبرد !
و اگر هر پيك بتواند براي چند مشتري جنس ببرد رابطه به صورت 1 به M خواهد بود
پيك A براي مشتري 111و222و444 جنس ميبرد !

[mohsensaghafi]

اين رابطه 1 به 1 هست چون براي هر مشتري فقط يك فاكتور صادر ميشود و هر فاكتور متعلق به يك مشتري است)‌

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

در ضمن فاکتور هم جزء موجودیت ها است. چون نمی توانید آنرا حذف کنید. اگر حذف شود، سفارش معنی ندارد.

[mf_007]

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

یا نه فاکتور رو باید به عنوان یک موجودیت به صورت کامل ذخیره کرد؟

[majidmir]

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

در ضمن فاکتور هم جزء موجودیت ها است. چون نمی توانید آنرا حذف کنید. اگر حذف شود، سفارش معنی ندارد.

سلام
دوست عزيز با اين حرفتون كاملا موافقم چون هر مشتری ممکن است چندین فاکتور داشته باشد ولي به نظرم من در هر بار براي هر مشتري فقط يك فاكتور در نظر گرفته ميشود ( البته ميگم كه به محيط عملياتي بستگي داره)
مشتري A قصد دارد ميز 111 و 222 و 333 را حساب كند براي هر ميز يك فاكتور جداگانه صادر مي شود و درستش هم همينه كه براي هر ميز يك فاكتور صادر شود و يا براي چند ادرس مشتري قصد خريد داشته باشد در اين صورت هم چند فاكتور جداگانه صادر مي شود :چشمک:
***
مشتري خريد ميكند كالا را ( كه فاكتور در رابطه خريد قرار ميگرد ( البته اينو مطمئن نيستم !))

[taghvajou]

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

یا نه فاکتور رو باید به عنوان یک موجودیت به صورت کامل ذخیره کرد؟

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

[mf_007]

ارتباط پیک رو چیکار کنم؟ با چی ارتباط بدم؟با مشتری یا فروش؟
ارتباطش بلاخره چند به چند شد؟

[majidmir]

ارتباط پیک رو چیکار کنم؟ با چی ارتباط بدم؟با مشتری یا فروش؟
ارتباطش بلاخره چند به چند شد؟


دوست عزيز بهترين كار اينه كه نموداري كه خودت كشيدي رو اينجا بزاري تا ببينيم و ويرايشش كنيم !

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


فروش ميشه ارتباط نه موجوديت ؟
حالا اين نمودار رو ببينم من خودم واسه پروژم اينو طراحي كردم(شركت پخش مواد غذايي ( البته اشكال هم داره ولي ببين با نمودار مد نظر خودت مطابقت داره يا نه ؟‌)‌

[taghvajou]

مهندس مجید! من مخالف نمودار شمام! به نظر من نباید بین مشتری و پیک رابطه باشه و باید سفارش (یا به قول دوستمون فروش) رو یه ماهیت مستقل در نظربگیریم
و

[majidmir]

مهندس مجید! من مخالف نمودار شمام! به نظر من نباید بین مشتری و پیک رابطه باشه و باید سفارش (یا به قول دوستمون فروش) رو یه ماهیت مستقل در نظربگیریم
و
دوست عزيز ميشه نموداري كه مد نظرته طراحي كني و بزاري ؟ در هر صورت به نظر من بايد بين پيك و مشتري رابطه باشه در غير اينصورت پيك كالا ( سفارش ) رو بايد چكار كنه ‌؟:متفکر::لبخندساده:

[mf_007]

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

یه کم کجو کولس با پینت کشیدم

[taghvajou]

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

دست آخر هم بین سفارش و پیک هم یه اکشن داشته باشیم به نام تحویل سفارش!

[taghvajou]

دلیلی نداره بین مشتری حضوری و تلفنی فرقی قائل باشی؟؟؟!؟!؟!؟:متفکر:

[mf_007]

اطلاعاتی که برای مشتری تلفنی ثبت می شه با اطلاعاتی که برای مشتری حضوری ثبت می شه فرق می کنه مشتری حضوری می تونه سفارشات بزرگ بده برا چند روزه دیگه و باید بیاد و مقداری از هزینه رو پرداخت کنه تا به سفارشش رسیدگی بشه ولی مشتری تلفنی نمی تونه همچین سفارشاتی رو بده (این سیستم یه مغازه که انواع نان فانتزی رو می فروشه و یه قسمت کارگاه هم داره که من فعلا قسمت فروش رو مطرح کردم)

[taghvajou]

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

[mf_007]

فروش رو اگه به صورت یک رابطه که صفت داره در نظر بگیریم فکر کنم درست تر باشه
این er چطوره ایراد داره؟

[taghvajou]

احسنت!
این هم ساده و جوابگویه! هر چند بخوایم آینده بینی و توسعه داشته باشیم، اما و اگر داره.
راه افتادی ها!

[mf_007]

taghvajou (http://www.barnamenevis.org/forum/member.php?u=69359)
ممنون از شما و بقیه دوستان که راهنمایی کردین