Icehouse

Trackback trial

Track back to Mandurro's Laptop issue

I'm just testing out the track back thing during class.

Hard Exam

I thought that sometimes the wording of the quesitons made them more difficult than they already were. I was really thrown off on the second section when we were supposed to assume the two relationships were correct and the fields used didn't logically make sense. I can't remember exactly what it was, but i beleive the relations said that section Id functionally determine prof id and student id. If I was correct, then each seciton only had one student... this was confusing since course sections should be able to have multiple students. If I was wrong about this, then the question was not as confusing as I tought and I obviously got the quesiton wrong.

Remembering Associative Entities

Here is the way I use to remember how to do the cardinalities for associative entities:

1) Picture/draw the ER diagram Many-to-Many relationship between the two entity types (without the associative entity).
2) Add the box for the associative entity inbetween them.
3) Move each of the two cardinalities that are next to the two entity type boxes so they are on the opposite sides of the associative enitity box (in other words, next to the associative entity box but on the other side of it).
4) Put 1:1 cardinality next to the boxes for both entity types

You can tell that this is right because the crows feet that represent each side of the Many-to-Many relationship are facing towards the same enitity type (as if the associative entity wasn't there).

This really only maters when the two minimums are different (i.e. one is 1:M and the ohter is 0:M).

P.S. Bud, this is a post that got overwritten a week or two ago when I tried to make a new post right after saving it.

SQL vs Access for Queries

For some odd reason, I find it easier to make queries using SQL than using the Access Design View. The design view just confuses me when I'm trying to do queries, but I love using it to create tables in Access. I wonder if by the end of the semester we all are going to like using SQL over any Design View..... kind of like how some people like writing HTML code themselves instead of using software like Frontpage to do it for them.

No Ambiguity About ER#3

I think there is no ambiguity about question 8 in ER Exercise #3. The fewest number of professors who can have a position in a college is 0. The reason is that a college can have 0 departments. No departments means no professors with positions.

If you start your analysis by looking at Prof first and making your way through Position and Dept to get to College, all you find out is that if there is a professor, there has to be a department and that if there is a department, then there has to be a professor. However, this does not mean there has to be a professor. Your analysis has to start by looking at College entity first.

Remembering Foreign Keys

I found that sometimes things just need to be explained in a different way so here is my shot at it:

Whenever you have a Many-to-Many (M:M) relationship between two entity types, that relationship table should have a foreign key that refers back to both entity types. For example, in ER Exercise #1, the "Wrote" relationship table will have a Foreign key that will refer back to both Paper and Author.

Whenever you have a One-to-Many (1:M) relationship, the table for the "Many" entity type will have a foreign key that refers back to the "One" entity type. For example, since one journal can have many issues, the Issue table should have a foreign key that refers back to the Journal entity type.

Another way to remember this is to ask, "Which way would not require adding extra records?" To answer this, picture each table without the foreign key. When you try to add a foreign key field(s) to the Journal table (the "One" entity type), you would also have to add additional records (rows) since one journal can have many issues. This causes repetition, which is a violation of 1st Normal Form. However, if you add a foreign key field(s) to Issues, all you add is that field(s). The number of records remain the same.

I hope this helps.

No Null in Primary Key Fields

It case anyone in class missed my comment...

When you say that a set of fields compose the primary key, you are saying that by knowing the values of those fields you can correctly identify the values of the fields in the rest of the record. And since a primary key is a candidate key, then you need all the fields in order to correctly know the values of the rest of the records. Therefore, if you have a null value in one of the primary key fields, then you dont actually need that field to determine the rest of the fields, which means the primary key is not a candidate key (since it can be further reduced).

So if you ever find out that one of your primary key fields is null, then your primary key is not a candidate key and you'll need to change it. Either choose a different candidate key or remove that one field from your primary key and check to see if its a candidate key.

Is reading necessary

While reading the normalization chapter from our coursepack, I realized that it wasnt adding anything new that Bud didnt cover. Did anyone else think this? I'm wondering if anyone went and did the problems without reading the material.

Remembering 3NF

I like the analogy (or whatever the correct word is) used to describe getting to 3NF by removing transitive dependencies. Remembering "All attributes depend on the key, the whole key, and nothing but the key" makes it a lot easier than trying to remember that transitive dependencies are attributes that..... well I'm not sure exactly how to phrase it.

test

horray test