تحلیل یک برنامه زیر شاخه دار

[teymoorei]

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

http://up.iranblog.com/images/xe1ajvghjvu67ie93jq4.png

زبان برنامه نویسی vb.net
پایگاه داده SQL 2008
لطفا کمک کنید چطور باید این پایگاه داده رو طراحی کنم و برنامه نویسی کنم .

[یوسف زالی]

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

73027

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

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

موفق باشید دوست من.

[Galawij]

yousijoon

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

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

[یوسف زالی]

خیلی زحمت نداره جناب galavezh
راه حل پیشنهادی شما چی هست؟
فکر می کنم راه اصولی همین باشه.
متقاعدم کنید.

[teymoorei]

سلام
خیلی ممنون از راهنمایی هاتون
اما کاری که من کردم این بود که :
4 تا جدول درست کردم که در هر جدول یه Catgory بود و یک ID یک IDT که در فیلد IDT شماره ID جدول قبل ذخیره میشه و با این کار داده هارو جستجو می کنم و در جدول 4 یا همون Catgory 4 (جدول آخر) علاوه بر دو فیلد ID و IDT فیلد هایی از غبیل نام و توضیحات و جود داره .
حالا من دوتا سوال دارم :
1- آیا این روش خوبه اگه بده چرا ؟
2- ببینید شاید کاربر بخواد فقط یک Catgory رو پر کنه و بعد هم بره Catgory آخر رو که می تونه توضیحات در باره برنامه بده رو پر کنه حالا من چطور اون 2 تایی که خالی هستن رو پر کنم یا اصلا چطور پر نکنم و یک راست برم سر Catgory آخر ؟

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

[یوسف زالی]

سلام.
تا جایی که متوجه شدم هر جدول برای یک سطح در نظر گرفته شده.
اگر همیشه همین سطوح باشند و زیاد نشوند برای کارهای کوچک خوبه.
اما همچنان من اصرار به استفاده از روش پیشنهادی ام دارم.
ممکنه روزی بخواهید داده ها و سطوح بیشتری داشته باشید.
در مورد سوال دوم، خودش یکی از ایرادات سوال اوله.
اما راه داره:
برای سطوح دوم و سوم داده ای وارد کنید به نام نامعین.
اگر کاربر فقط گروه اول را انتخاب کرد و رفت سراغ داده، جای کاربر، خودتون مقدار نامعین رو انتخاب کنید.
اگر هم نمی خواهید در select ها و گزارشات مقدار نامعین دیده نشه با کدهای T-SQL به راحتی این کار رو کنید.

[teymoorei]

با این که منظورتون رو از داده ی نامعیین متوجه نشدم اما بازم خیلی کمک کردید ، ممنونم .

[یوسف زالی]

منظور من اینه که اگر null بود لینکش بدبد به ردیفی که در اون نوشته نامعین.
مثلا:
breaking then habit --> null --> null --> Song
بشه:
breaking the habit --> unknown --> unknown --> Song
موفق باشید.

[teymoorei]

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

[Galawij]

yousijoon

نقل قول: تحلیل یک برنامه زیر شاخه دار
خیلی زحمت نداره جناب galavezh
راه حل پیشنهادی شما چی هست؟
فکر می کنم راه اصولی همین باشه.
متقاعدم کنید.

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

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

[teymoorei]

سلام
خیلی خوشحالم کردید چون منم دقیقا همین راه رو انتخاب کردم و پیاده سازی کردم .
و در نهایت هدف من از ایجاد این تاپیک 2 سوالی بود که من در پست 7 پرسیدم .


1- آیا این روش خوبه اگه بده چرا ؟
2- ببینید شاید کاربر بخواد فقط یک Catgory رو پر کنه و بعد هم بره Catgory آخر رو که می تونه توضیحات در باره برنامه بده رو پر کنه حالا من چطور اون 2 تایی که خالی هستن رو پر کنم یا اصلا چطور پر نکنم و یک راست برم سر Catgory آخر ؟
فقط اگه میشه سوال دومم رو کمی برام توضیح بدید .

[یوسف زالی]

جناب galavezh :


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

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

[teymoorei]

ببینید اگه اون دو Catgory خالی رو پرکنم حالا با هر چیزی یکسری داده ی بیخودی ذخیره کردم من می خوام ببینم راهی نداره که مثلا از Catgory اول بپرم به Catgory چهارم یا این دوتارو به هم مرتبط کنم و خالی هارو نا دید بگیرم .
باتشکر

[Galawij]

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

[یوسف زالی]

ولی در مورد سطح دوم که منظورتون روی موضوعات فرعی هست، دلیلی نمی بینم که این سطح تعیین نشود،

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

[panahgah]

شما به اين ترتيب بر اساس گروه بندي كه شده براي هر گروه يك چجدول درست كرديد .

مشكل منم يك برنامه زير شاخه دار هست با اين تفاوت كه گروه بندي نشده يعني پدر و فرزند هر دو داراي يك سري فيلد هاي مشخص هستند .

اگه مي شه راهنمايي كنيد ؟

[یوسف زالی]

یعنی کد پدر در فرزند قرار نداره؟
از کجا می فهمید کی فرزند کیه؟

[panahgah]

چرا قرار داره ، اما بقيه فيلد ها در فرزند و پدر يكي هستند . مي شه فهميد كه اين پدر فرزنداش كي هستند اما مشكل اونجچاست كه پدر فرزندي خودش فرزند باشه .

[panahgah]

يه چجستجچويي كه در اينترنت كردم به اين برخوردم

team و يه subteam بود

team =>teamID<pk>,Name
subteam=> subteamID<pk><fk> ,teamID<pk><fk>, Name

اما وقتي من انو تست مي كنم چواب نميده
مثلا فرض كنيد كه A پدر باشه و داراي دو فرند B ,C باشه و حالا B داراي يه فرزند D باشه

جدول ها به اين صورت مي شه كه
team=>1,A
Subteam=>1,1,B
subteam=>2,1,C
subteam=>3,1,D
در ركورد سوم كه آيدي پدرش 1 هست به اين ترتيب مشخص نمي شه كه پدرش B هست يا A ?

[panahgah]

از اونجچايي كه هيچج كدوم از دوستان به اين مطلب جچواب ندادند ،

فكري به نظرم رسيد : براي اينكه ايدي هاي جدول team و subteam با هم قاطي نشه
بهتر هست كه identity seed رو مثلا از شماره 1000 بذاريم .

حالا نمي دونم اين افكار من درست هست يا يه ، اگه دوستان كمك كنيد ممنون مي شم .

[Kubuntu]

با galavezh (http://barnamenevis.org/member.php?60171-galavezh) موافقم!
چون طراحی جداولشون براساس نرمالسازی و همچنین بهینه است!
اگه می خواهید بعدا با مشکل برنخورید پیشنهاد می کنم جدوالتون را براساس galavezh (http://barnamenevis.org/member.php?60171-galavezh) طراحی کنید.

یادآوری: چنانچه کلید خارجی بسته به نیاز بتواند در یک جدول null بپذیرد، حتما تیک null رو بزنید.

موفق باشید

[یوسف زالی]

اگه می خواهید بعدا با مشکل برنخورید


اگر بعدا بخواهیم دو سطح دیگه اضافه کنیم چطور این کارو می کنیم؟
جناب kubuntu لطفا برای ما توضیح بدهید.
ممنون

[Galawij]

مثلا فرض كنيد كه A پدر باشه و داراي دو فرند B ,C باشه و حالا B داراي يه فرزند D باشه

جدول ها به اين صورت مي شه كه
team=>1,A
Subteam=>1,1,B
subteam=>2,1,C
subteam=>3,1,D
در ركورد سوم كه آيدي پدرش 1 هست به اين ترتيب مشخص نمي شه كه پدرش B هست يا A ?
ساختار درختی خیلی راحت این مشکل را حل می کند. به این صورت:
A,Null,1
2,1,B
3,1,C
4,2,D

panahgah

نقل قول: تحلیل یک برنامه زیر شاخه دار
از اونجچايي كه هيچج كدوم از دوستان به اين مطلب جچواب ندادند ،

فكري به نظرم رسيد : براي اينكه ايدي هاي جدول team و subteam با هم قاطي نشه
بهتر هست كه identity seed رو مثلا از شماره 1000 بذاريم .

حالا نمي دونم اين افكار من درست هست يا يه ، اگه دوستان كمك كنيد ممنون مي شم .
حالا اگر تعداد رکوردها از 1000 تا بیشتر بشه می دونید چه اتفاقی می افته؟؟؟!!!

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

[یوسف زالی]

با kubuntu در خصوص نرمال بودن و نبودن موافق نیستم.


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

این حرف رو کاملا قبول دارم. در حقیقت من روش کلی را پیشنهاد دادم و گفتم که برای مصارف آینده گسترش رو آسون می کنه.
اما اگر همیشه همین تعداد سطح هست روش شما راحت تره.
اما


در ادامه دیدیم که ساختار پیشنهادی شما نیاز کابر را به تأمین نمی کرد.

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

این تاپیک ادامه دارد..

[Galawij]

چون نیاز کاربر متفاوت بود، عرض کردم و الا روش شما که یک موضوع ثابت شده هست. نمی شه که به تعداد زیادی در جدول مقدار Null بذاریم.

[حمیدرضاصادقیان]

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

در جدول لیست خواننده ها فیلد ها به این شکل هستند:
کدپدر - کدفرزند -عنوان.

جدول آهنگ های خواننده به این شکل هست:
کد خواننده - کد آهنگ - نام آهنگ ( که این کد خواننده با جدول بالایی ارتباط خواهد داشت)

در این روش شما میتوانید خواننده ها را به 10 مرحله یا بیشتر تجزیه کنید.

[Kubuntu]

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

جدول آهنگ های خواننده به این شکل هست:
کد خواننده - کد آهنگ - نام آهنگ ( که این کد خواننده با جدول بالایی ارتباط خواهد داشت)

در این روش شما میتوانید خواننده ها را به 10 مرحله یا بیشتر تجزیه کنید.

در این حالت ریلیشن ها بصورت زیر می شه؟؟
کد پدر (یک)به کد خواننده (چند)
کد آهنگ(یک) به کد فرزند(؟) رابطه این قسمت یه طوریه!