Comments on this database design??

Looks OK.
one comment,
You have it set up that a product can be supplied by many suppliers.  Is this really true?
if so I would have thought that whn you sell a product (SalesDetails) will you not have to indicate which supplier is going to supply the product? you have it set for the purchase order details

/Richard

Hello,

One thing i was thinking while looking at it is maybe you want to segrigate username and password into a seprate table so that you can key them.  the way it is now two diffrent employee's could have the same username and diffrent passwords, not sure how that would work :)

-Navicerts

Also looking at three fields in your PurchaseOrders table I am wondering if one of them is a calculated field or not?

I see DateOrdered, DateRequired, and DateRequested.  I don't know if it is the case or not but i thought that some companies might have the "date required" be simply the date it was promised - 2 buisness days or something.  Once again i dont know if this is the way your company works but it was just a thought.

-Navicerts

The comments are very useful... Great job..

By the way the database design is for a warehouse.

I further have some probs:
i need the tables to be in 3rd normal form..

I am getting a confusion:
i think there are partial dependencies on the table PurchaseOrdersDetails as, i think QTY depends on ProductID which is part of a Composite primary key.

the same probs for SalesDetails...

The main issue is normalisation..

How can the transitive dependencies be solved?

"i think there are partial dependencies on the table PurchaseOrdersDetails"
I don't think so - if QTY only depended on ProductID, and not also on OrderID that could tell how many were ordered, just by knowing the product, and not knowing which order it actaully wasy (i.e. that all orders for a product were for the saem quantitiy), which I presume is not the case in your world. If it is true (which  it may be - if there is a rule that people must always order the same quantity, and if they require more, they must place a new order....) that the QTY ordered depends only on the product, then remove QTY from this table, and put it in the Product Table.
The only problem with your PurchaseOrderDetails table is that the relationship should be between PurchaseOrderDetails and Supplies, not to Supplier & Product sepertately.

"How can the transitive dependencies be solved?" nobody in the real world ever asks such a question. Can I assume that this is homework related? From your model there is no obvious transitive dependencies, but this is not always evident from the model itself, but may be deduced from the buisness rules involved etc. We are not in a position to do homework for you, nor to provide general training in database theory, but rather to answer specific problems etc. If you have a specific problem regarding normalisation that you need help with, detail the issue and we can give further assistance.

"How can the transitive dependencies be solved?"

Like BillAn1 mentioned i really don't view things in that way.  Hmm, i suppose this would be like the math property where A > B and B > C therefore A > C.  

All your relations seem fairly direct, perhaps it is best to think of your DB in a more "common sense" type of approach.

Sorry i can't help you much more on that one.

-Navicerts

Not a hw question.. i am learning to create databases in sql server.. i want to create nice normalised tables..

i corrected some of the errors i made.

I think one of the main things to keep in mind when you are trying to create a normalized DB is will you be able to change the way you do buisness without changing the DB signifigantly?

For instance...

Currently on the DB i am working on they weighed animals twice in thier life, for this they had a table with the following (along with sevral other columns but ill keep it simple).

Animal ID
Weight One
Weight Two

Now they way that is set up now (NOT normalized) if they wanted to weight animals three times in thier life it would require a signifigant change in the system so i changed it to the following...

Animal ID
Weight
Date

This way they can weight the animals as many times as they want throughout its life with no change to the DB.  I think these are some of the things you need to keep in mind.

-Will they be able to change the way they do things (is my DB robust)
-Will they be able to ask all sorts of questions of your DB, find out what they want from it first and make sure they can get all this information
-Can you add new things into your DB without having a lot of hardships
-Will your data remain valid, good integrity checking!!

Good Luck

-Navicerts

Ya its regarding flexibility...

i think there are too many assumptions that have to be made...
or rather study the system deeply..

i think flexibility is the hardest part in database design.