Hi,

I'm fairly new to database modelling.
I need some pointers on how to model a good database, like what attribute an entity should has, how to parse your data, etc.

FYI,
I'm developing a large database for a medical application to locate medical entities (hospitals, doctors, etc.) and retrieve their infos.
there will also be a realtion between doctors and hospitals concerning the practice schedule and location of practice.

any help would be greatly appreciated, even general rule of thumbs (I really am a newbie at this).

This is not something you can learn by getting a few tips on this forum. Go to a book store (e.g. Amazon) and search for "database design", and find a recommended book suitable for a beginner.

I can't understand why organisations entrust the development of (presumably important) "large databases" to people who have zero experience. No disrespect to you (we all have to start somewhere), but they presumably wouldn't ask you to design a new hospital wing without knowing you to be a qualified architect first, would they?

well I'd been exposed to larger DB than this (in the entity relationship sense). I just never design a DB model from bottom up before. not to disrespect any professional DB people out there, but I always thought modelling DB doesn't involve any complicated science. I'm just an apprentince BTW, someone else is doing the design actually, I'm just helping.

well, according to my inexperienced gut feeling, this DB should be enough with a few tables with lots of tuples in them.
my initial design I partition a hospital entity into: general info, location, contact, a table for fixed values and a table for varying values.
anyone see anything wrong with this?

if this subject is too vast to be discussed here please tell me, otherwise don't worry to use any DB jargons, I already have a reference book.

True, it is largely a matter of common sense backed up by experience. The science (e.g. normalisation rules) defines a good database model mathematically, but it is mostly "obvious" - e.g. don't store the customer's name, address and telephone number on every order line.

Hmm...?

It really isn't possible to quality check your design based solely on the table names - though "a table for fixed values and a table for varying values" sounds odd. Try following the normalisation rules for 1st, 2nd and 3rd normal form to see if your design is properly normalised.

normalisation? I'll check on that, thanks.

is eliminating any redudancy thus making a DB as small as possible always the way to go when designing a DB? or is there a trap in this practice?
could you give some more rule of thumbs for designing a DB?

Take a look at this link, you may find it helpful:

http://www.utexas.edu/its/windows/da.../datamodeling/

Here is something you can try:

First write the use cases like:

admin -> (locate medical entity) << include >> (locate hospital), (locate doctor)
admin -> (retrieve info) << include >> (retrieve hospital info), (retrieve doctor info)

assistant -> (schedule doctor) << include >> (assign doctor to location)

etc. and then derive a DB using an approach like:
http://www.mycgiserver.com/~nsenthil...ndbdesign.html

Hope that helps,
Nalla