TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

A Simple Guide to Five Normal Forms in Relational Database Theory

135 点作者 b-man将近 15 年前

10 条评论

novum将近 15 年前
I do a lot of interviews for software developers, and I ask a very simple database normalization question that close to half of the candidates miss completely.<p>Something like: "You're tracking doctors, hospitals, and patients. Doctors can see multiple patients, and doctors can staff multiple hospitals". All I'm looking for you to say is that you'd put junction tables between the main entities.<p>It's so, so crucial that developers understand the basics of database design, and normalization is a huge part of that.
评论 #1566361 未加载
评论 #1566290 未加载
评论 #1568034 未加载
评论 #1566392 未加载
评论 #1568223 未加载
评论 #1566432 未加载
评论 #1566295 未加载
btilly将近 15 年前
You understand everything most developers should ever need to know about normalization if you get the following two sentences.<p><i>The key, the whole key, and nothing but the key. So help me Codd.</i><p>(For those who don't get it, the first sentence describes first, second and third normal forms, and the second sentence names the guy who is responsible for most of the theory behind them.)
sovande将近 15 年前
Thanks, nice to get a refresher on the fifth normal form. Though in practice I have yet to see anything behind the third normal form used; "The Key, the whole Key, and nothing but the Key, so help me Codd"
评论 #1567778 未加载
slim将近 15 年前
Don't take it for granted.<p>With modern software design and especially OOP the risk of data inconsistency is less of a problem (I do web apps for entreprise and it simply never happened to me).<p>On the other hand duplication of information is a great way to scale an application. And incidentally offers data security since you can cross check your data in case of corruption.
评论 #1567775 未加载
Another1将近 15 年前
If you want to learn the relational model using a fairly slim book, i cant recommend "Practical Issues in Database Management" by Fabian Pascal enough for you!<p>And always remember, relational theory is one thing, and popular RDBMS is another.
maxdemarzi将近 15 年前
Software developers and SQL developers can both usually figure out how to get what they want out of the database...<p>The problem is the software developer may rely on loops ( and variables, and cursors and temporary tables and dynamically generated sql, the horror) to do his thing while the SQL developer will use set theory to avoid as much of that as possible.<p>They both rely on what they know, it's just that one persons knowledge is better suited for programming and the other is specific to relational databases.
评论 #1568057 未加载
grk将近 15 年前
I've always thought that 5NF is a bit overkill. Didn't find one decent example that would make me say "oh, so that's why they do it".<p>I must say though, after the Database Systems course at DTU, when I come up with a DB design it's almost always in 4NF to start with :). Man, I hated this course.
alan-crowe将近 15 年前
I know so little about relational databases that I'm worried about being misled by an unreliable guide found on the internet. Reading suspiciously, this guide seems garbled.<p>Section 3, second and third normal forms, says "Under second and third normal forms, a non-key field must provide a fact about the key, us the whole key, and nothing but the key. In addition, the record must satisfy first normal form."<p>There seems to be a stray word "us". Ignoring that, this is cute word play that doesn't quite make sense. If your table has non-key fields you are inevitably providing facts about the non-key fields.<p>Continuing,<p>"We deal now only with "single-valued" facts. The fact could be a one-to-many relationship, such as the department of an employee, or a one-to-one relationship, such as the spouse of an employee."<p>This is the wrong way round. Usually there are lots of employees and a few deparments. Each employee works for just one department, but each department has many employees. Thus the "department of an employee" is a many-to-one relation, or function, which takes an employee and yields a department. The one-to-many relationship here is the employee list of a department.<p>The example for 3.2 seems to be opening the wrong can of worms. Suppose that Mr Strauss, who works for the department of waltz in Vienna, is seconded to the department of piety in Rome, in order to teach them some dance steps. Then we want his row in the database to read<p>(Straus, Waltz, Rome)<p>So one can of worms is sticking generic labels on your fields. If you label your fields (Employee, Department, Employee-location) there is no problem. If you label your fields (Employee, Department, Department-location) you have a problem, but it is obvious. If you label your fields (Employee, Department, Location) you are heading for trouble as some users of the database fill in the location of department and other users of the database fill in the location of the employee.<p>Hmm, second and third normal form are suspiciously similar, differing only because we regard some fields as belonging to the key. Is the article trustworthy?
cmurphycode将近 15 年前
I studied this summary before my most recent interview. It's a little abstract (in terms of lacking motivation/examples) for those who don't have experience in the field, but if you read it enough times, you get a decent handle on the idea.
评论 #1572306 未加载
dennisgorelik将近 15 年前
Did anyone notice how many grammatical mistakes that article has?