Just feedback if you want to improve the discussion. 1) The example rows use first name and last initial for Client primary key attribute (e.g James H.). No o

Just feedback if you want to improve the discussion. 1) The example rows use first name and last initial for Client primary key attribute (e.g James H.). No one uses this in the real world for a name-based primary key. In fact, in a sufficiently large enough system, you would _never_ use a name for a primary key since names are not guaranteed to be unique. 2) Functional dependencies are interesting ideas. The discussion says that studID (student id) determines address. It would be beneficial to further discuss how we know that. For instance, more than one student could live at the same address. And a student could live at more than one address. So does studID truly determine address? Does the dependent attribute have to be unique? Does the determinant set? 3) The discussion moves from Data(studID, studName, ...) to breaking it out to three entities and says "The following structure is considerably better." But what criteria make it better? 4) It states that "Each student has his own address", but in the real-world that's not _always_ true. There will be cases when a student does not have an address, or the address is still unknown. Also, mailing address and physical addresses can be two different attributes. I'm being picky, right? But these things come up all of the time (so much so it gives me heartburn). So using good examples will help prevent future bad designs I believe. 5) courseID is supposedly functionally dependent on courseName. Again, courseNames can be non-unique in a real school. And courseID domain and range would be important to know whether courseID is unique. For instance there are many 101 courses out there. So is this a sequentially generated ID, a GUID? Only then can we know if it's truly unique. 6) Now to the really good stuff. Functional dependencies are abstractions that exist outside of the database logical and physical design and implementation correct? What if we identified all of the functional dependencies in our entities? Could we generate a good table design automatically from that? How do we prevent from modeling the entire universe and how do we prove that we've over-modeled? (I think one of the stated benefits of relation models is that once, you get to 3NF you can expand the model as needed. So how do we use FDs to determine whether we are 3NF)? Interesting reduction of FDs to mathematical concepts, but to make it useful to a practitioner, more to go.