সাধারণকরণ: এটি কি এক বছরের মতো স্থিতিশীল, সংখ্যাগত মানগুলিকে তাদের নিজস্ব টেবিলে বিভক্ত করার জন্য উপযুক্ত বলে বিবেচিত হয়?


16

নরমালাইজেশন সম্পর্কে আমি অন্য একটি ডাটাবেস ডিজাইনারের সাথে একটি আকর্ষণীয় আলোচনা করছি। এই উদাহরণস্বরূপ, আমাদের একটি গেমিটলস টেবিল রয়েছে এবং প্রতিটি রেকর্ডে অবশ্যই গেমটি প্রকাশিত হয়েছিল contain তিনি বলেছিলেন 2 এনএফ আদেশ দেয় যে সমস্ত কিছু অবশ্যই স্বাভাবিক করা উচিত, সুতরাং, অনুগত হওয়ার জন্য, বছরের ক্ষেত্রটি তার নিজস্ব প্রাথমিক কী সহ একটি রিলিজ ক্লারস টেবিলের মধ্যে বিভক্ত হওয়া উচিত যা গেমিটলস টেবিল দ্বারা উল্লেখ করা হয়। আমি বলছি এটি গেম শিরোনামের টেবিলে নিজেই একটি ক্ষেত্র হিসাবে থাকা উচিত।

এর জন্য আমার যুক্তিটি হল যে একটি বছর কেবল একটি প্রাক-প্রাকৃতিক সংখ্যাসূচক মান যা এর প্রকৃতির দ্বারা স্থির থাকে (যেমন, 2011 সর্বদা 2011 হবে)। এ কারণে এটি এর নিজস্ব সনাক্তকারী হিসাবে কাজ করে এবং এটি যা তা তাই এটির রেফারেন্স দেওয়ার মতো কোনও কিছুর প্রয়োজন নেই। এটি অতিরিক্ত রক্ষণাবেক্ষণেরও সূচনা করে যেহেতু এখন আপনাকে কেবলমাত্র রেফারেন্সের জন্য টেবিলে একটি নতুন বছর যুক্ত করতে হবে। আপনি যদি বছরের বড় পরিসীমা সহ টেবিলটি প্রিপোপুলেট করেন তবে আপনার কাছে অতিরিক্ত রেকর্ড রয়েছে যা সম্ভবত তাদের কাছে কোনও উল্লেখ নেই। এটি এখন ডাটাবেসের আকারও বাড়ায় যেহেতু এখন আপনার নিজের জন্য অতিরিক্ত টেবিল, রেকর্ড ওভারহেড এবং সেই বছরের জন্য অতিরিক্ত প্রাথমিক কী রয়েছে। আপনি যদি বছরটি গেমিটলস টেবিলের ক্ষেত্র হিসাবে রাখেন, আপনি এই সমস্ত অতিরিক্ত রক্ষণাবেক্ষণ এবং ওভারহেড অপসারণ করবেন।

এ নিয়ে ভাবনা?

সম্পাদনা করুন: স্ট্যাকওভারফ্লোতে এটি পোস্ট করার অর্থ। কেউ কি এটি মুছে ফেলার জন্য ভোট দিতে পারে বা মনোযোগের জন্য এটি পতাকাঙ্কিত করতে পারে?


6
কেন? এটি এখানে একটি ভাল ফিট মত মনে হচ্ছে।
লেইফ রিফেল

আমি যে প্রশ্নটি জিজ্ঞাসা করতে চাই তা হ'ল আপনি কি এটি স্বাভাবিককরণ বা প্রকৃত উত্পাদন প্রয়োজনের বিষয়ে জিজ্ঞাসা করছেন? উত্পাদনের জন্য আমি জিজ্ঞাসা করব এটি করার একটি কার্যকর জিনিস কিনা?
jcolebrand

উত্তর:


14

অন্যান্য ডাটাবেস ডিজাইনার সহজভাবে ভুল, তবে আপনার যুক্তিটিও ভুল। ধরে নেওয়া যাক আপনি এই টেবিলটি দিয়ে শুরু করেছেন, যার একক প্রার্থী কী, "গেম_টাইটেল" রয়েছে।

Table: game_titles

game_title                      year_first_released
--
The first game                  1998
The second game                 1999
Best game: the third one        2001
The fourth game                 2003
Forty-two, the end of games     2011

নিজেকে এই প্রশ্নগুলি জিজ্ঞাসা করে এটি 2NF- এ রয়েছে কিনা তা আপনি মূল্যায়ন করে।

প্রশ্ন: প্রথমত, এটি 1NF এ আছে?

উত্তর: হ্যাঁ, তাই

প্রশ্ন: প্রধান বৈশিষ্ট্যগুলি কী কী (প্রার্থী কী এর অংশবিধিত্বকারী গুণাবলী)?

উত্তর: "গেম_টাইটেল" হ'ল একমাত্র প্রধান বৈশিষ্ট্য।

প্রশ্ন: অ-মৌলিক বৈশিষ্ট্যগুলি কী কী?

উ: "বছরের_সর্বস্ব_প্রকাশিত" একমাত্র।

প্রশ্ন: "গেম_টাইটেল" পুরোটির উপর নির্ভর করে "ইয়ার_ফার্সট_ রিলিজেড" বা এটির কেবলমাত্র একটি অংশের উপর?

উত্তর: একমাত্র প্রার্থী কী, "গেম_টাইটেল", একটি একক কলাম; এর অংশও নেই। সুতরাং "Year_first_released" পুরো "গেম_টাইটেল" এর উপর নির্ভরশীল।

Voila। আপনি 2NF খুঁজে পেয়েছেন।

প্রথমে এটি 1NF- এ কিনা তা জিজ্ঞাসা করে এবং পরে এই প্রশ্নের উত্তর দিয়ে আপনি কিছু আনুষ্ঠানিক শর্তাদি কাটাতে পারেন।

প্রশ্ন: কোনও যৌথ প্রার্থী কী আছে?

উঃ না।

Voila। আপনি আবার 2NF খুঁজে পেয়েছেন।

সংজ্ঞা অনুসারে, 2NF লঙ্ঘন করতে কোনও টেবিলের জন্য, এতে কমপক্ষে একটি প্রার্থী কী থাকতে হবে যার একাধিক কলাম থাকতে পারে।

আপনার বন্ধুর মতামত প্রত্যাখ্যান করার জন্য এখানে আপনার কারণ রয়েছে।

  • এক বছর হল একটি অ-আদিম সংখ্যাগত মান।
  • একটি বছর তার প্রকৃতি দ্বারা স্থির হয়।
  • একটি বছর তার নিজস্ব সনাক্তকারী হিসাবে কাজ করে।
  • বছরের একটি সারণী অতিরিক্ত রক্ষণাবেক্ষণের পরিচয় দেয়।
  • বছরের একটি সারণীতে অতিরিক্ত সারি থাকতে পারে যা উল্লেখ করা হয়নি are
  • বছরের একটি সারণী ডাটাবেসের আকার বাড়ে।

এই কারণগুলির মধ্যে কোনও কোনও টেবিল 2NF- এ রয়েছে কিনা সেটির কোনও যোগসূত্র নেই।

একটি ডেটাবেস ডিজাইনে, রক্ষণাবেক্ষণ সংক্রান্ত সমস্যা, ডাটাবেসের আকার, অবাস্তব সারি, সীমার সীমাবদ্ধতা ইত্যাদি বিবেচনা করা ভুল নয়। এই জিনিসগুলিকে সাধারণীকরণ বলা ঠিক ভুল।

ওহ, এবং যে দুটি কলামের সারণী আমি উপরে সরবরাহ করেছি - এটি 5NF এ রয়েছে।


2
সুন্দরভাবে সম্পন্ন. আমি একটি উত্তর পোস্ট করতে প্রলুব্ধ হয়েছি যা আপনার প্রথম বাক্য ব্যতীত অন্য কিছুই বলেছিল না ... "অন্য ডাটাবেস ডিজাইনার কেবল ভুল", আপনি এটি খুব ভালভাবে কভার করেছেন।
মার্ক স্টোরী-স্মিথ

5

যে কোনও অ্যাট্রিবিউটের জন্য পৃথক টেবিল তৈরির সাথে সাধারণীকরণের কোনও সম্পর্ক নেই। 2 এনএফ, 3 এনএফ, বিসিএনএফ, 4 এনএফ, 5 এনএফ সমস্তই অ-কী নির্ভরতা দূর করার সাথে সম্পর্কিত। আপনি যদি কোনও নতুন টেবিলের কোনও একক বৈশিষ্ট্য অপসারণ করেন এবং এটিকে কোনও বিদেশী কী বৈশিষ্ট্য দিয়ে প্রতিস্থাপন করেন তবে সারণীর নির্ভরতাগুলি যুক্তিযুক্তভাবে আগের মতোই হবে - সুতরাং সারণির সংশোধিত সংস্করণটি এর চেয়ে বেশি বা কম স্বাভাবিক হবে না আগে ছিল।


আমি এটিতে কিছু যুক্ত করতে চাই , তবে কী হবে তা নিশ্চিত নয়। আপনি বলছেন যে কোনও টেবিলে 1: 1 পারস্পরিক সম্পর্ক রয়েছে এমন কোনও কিছুকে স্থানান্তরিত করা (এই ক্ষেত্রে যেমন 1 টিরূপে 1 টির মূল বা এক সারিতে এক সারি) সন্ধানের প্রয়োজন নেই, কোনও লাভ দেয় না, তাই না? তবে আপনার সম্ভাব্য অনুসন্ধানের সুবিধা রয়েছে যদি আপনার খুব কম বছরই প্রয়োজন হয় এবং আপনি কেবল 255 বছর বা তারও কম পরিসর খুঁজছেন। আপনি এখানে কয়েকটি সংরক্ষিত বাইটগুলি ধারণার সাথে দূরে সরিয়ে নিতে পারেন, তবে যেহেতু সাধারণত সেগুলি 4 বাইটস এ যাইহোক বরাদ্দ করা হয়, এটি কোনও যুক্তিসঙ্গত অনুমান নয়।
jcolebrand

1
@ জকোলেব্রান্ড: আপনি যা বলছেন তাতে সম্মত হন। তবুও প্রশ্নের উত্তর একই: আপনি এটি করেন বা না সেপ্টেম্বর প্রতি সাধারণীকরণের সাথে কিছুই করার নেই।
এনভিজেল

আমি একমত. যেমনটি আমি বলেছিলাম, আমার অর্ধেক হৃদয় ছিল "আমার মনে হয় ওপি এখানে কিছু অনুপস্থিত" ... কারণ আমি জানি না যে এই ধারণাটি নিয়ে কোথায় যাব।
jcolebrand

5

আমার দৃষ্টিকোণ থেকে একটি পৃথক বছরের ছকটি কেবল তখনই বোধগম্য হবে যদি "প্রকাশের বছর" কোনও ক্যালেন্ডার বছর না হয় তবে উদাহরণস্বরূপ এমন একটি আর্থিক বছর যা একাধিক ক্যালেন্ডার বছর বিস্তৃত করতে পারে (যেমন অক্টোবর থেকে অক্টোবরে যাওয়া)।

এই সারণিতে তারপরে অর্থবছরের সংজ্ঞা (আসল শুরু এবং শেষের তারিখ) রাখা হবে


1
+1 আপনার কেবলমাত্র কোনও টেবিলের প্রয়োজন যদি এটির বৈশিষ্ট্যগুলি থাকে> :)
জ্যাক বলেছেন topanswers.xyz ২

2

Http://en.wikedia.org/wiki/Second_normal_form থেকে :

একটি 1NF টেবিল 2NF এ থাকে এবং যদি কেবলমাত্র, কোনও প্রার্থীকে কী K এবং কোনও বৈশিষ্ট্য A দেওয়া হয় যা প্রার্থী কী এর উপাদান নয়, A এর কেবল একটি অংশের চেয়ে পুরো K এর উপর নির্ভর করে।

বছরটি প্রার্থী কী এর অংশ কিনা তা আপনি চিহ্নিত করেননি, তবে আমি নিশ্চিত নই যে এটি গুরুত্বপূর্ণ, কারণ উভয় ক্ষেত্রেই 2NF সন্তুষ্ট হবে যতক্ষণ না বছরের সম্পর্কিত।

ব্যবহারিক স্তরে আপনার তালিকাভুক্ত সমস্ত কারণে বছরের আলাদা করা খারাপ ধারণা।


2

এটির আকারের কারণে বা এতে অব্যবহৃত সারি থাকবে বলে আমি পৃথক সারণীর বিপরীতে যুক্তিটি অপছন্দ করি। এমনকি যদি আপনি এই টেবিলের মধ্যে 1000 বছর রাখেন তবে আকারটি নগণ্য হবে।

এটি বলেছিল, আমার মনে হয় না যে টেবিলটি একেবারেই প্রয়োজন। বছরের জন্য আলাদা টেবিল থাকার বিষয়টি কী? এই ডেটাটি ইতিমধ্যে মূল সারণীতে রয়েছে এবং আপনি দ্বিতীয় সারণী তৈরি করে একেবারে কিছুই সংরক্ষণ করেন না।

যুক্তিটি ক্যালেন্ডারের টেবিলের জন্য আলাদা হতে পারে, যেখানে প্রতিটি সারি একটি দিন উপস্থাপন করে এবং অন্যান্য বৈশিষ্ট্যগুলি থাকতে পারে (সপ্তাহের দিন, ইউটিসি অফসেট, এটি ছুটি হোক না কেন ইত্যাদি)।

তবে একা একা? নাহ, আমি মোটেই কোনও উপকার দেখছি না ... এবং অন্যরা যেমন উল্লেখ করেছে, তাদের জিজ্ঞাসা করুন কেন তারা ভাবেন যে এটিকে আরও সাধারণীকরণ করা হয়েছে? বা তারা কি লাভ? আপনি যদি কোয়েরি লিখার চেষ্টা করছেন

WHERE othertable.year = 2011

পরিবর্তে

WHERE dt >= 20110101 AND dt < 20120101

তারপরে আমি আপনাকে প্ররোচিত করার চেষ্টা করব যে পরেরটি পারফরম্যান্সের জন্য (ডিটি অনুমান করা হয়) এবং সঞ্চয়স্থানের জন্য আরও ভাল। কোডিংয়ের সরলতা যদি সর্বজনীন হয় তবে আমি বলব একটি স্থির গণিত কলামটি অন্য টেবিলের চেয়ে ভাল।


1

আমি ক্যাটাকলের জবাবের সাথে একমত ছাড়া পুরোপুরি একমত: "বছর" সর্বদা একটি আদিম মান নাও হতে পারে তবে আমার ধারণা, এটি একটি ডেটাবেস ডিজাইনের চেয়ে ব্যবসায়িক যুক্তি ধারণা more

একই নকশাটি রেখে, ধরে নেওয়া যাক যে বছরগুলি কেবল সেই বছরগুলিতে হওয়া উচিত যা মুক্তির জন্য অনুমোদিত। এইভাবে, আপনি আদিম সংখ্যাসমূহের সাথে আচরণ করছেন না, বরং সেগুলির একটি উপসেট এবং যেমন সাবসেটটির কোনও আদিম প্রয়োগ নেই, তাই আপনাকে নিজের কাজটি করতে হবে (একটি পৃথক টেবিল?) এবং এটি উল্লেখ করতে হবে (একটি এফকে সহ) এইভাবে, আমরা এখনও বছরের কথা বলছি, তবে আমাদের সেগুলি অন্যভাবে পরিচালনা করা দরকার, কারণ তারা ধারণাগতভাবে তাদের অর্থ পরিবর্তন করেছিল changed যাইহোক, তারা এখনও "মুক্তির বছর", তবে ডোমেন জ্ঞানের কারও কাছে তারা কী বোঝায় তা বিবেচনামূলকভাবে ভিন্ন।

এই নির্দিষ্ট ক্ষেত্রে, আমি আবার বলছি যে ক্যাটাকলের উত্তর সঠিক, তবে কেবল এটি উল্লেখ করতে চেয়েছিল। (দুঃখিত, মন্তব্য করার মতো পর্যাপ্ত প্রতিনিধি নেই।)

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.