Member Avatar for palavi

hi all,can anybody point out wats wrong in my database design, guide me right database ,i ve 4 tables i type all its attributes
its for hospital database
patient table
pid, pfname, plname, pcontactno, page, pplace ,pdocname, pprob ,ptype(this is for out patient,inpatient), pbill.
doctor table
docid ,docname, docplace ,doccontactno ,docdept
emp table
empid, empname, empcontactno ,empdept ,noofleave ,salary
bill table
patientid, p_pfname, doc_id, med_charges, ward_rent ,service charge ,total_bill.

all ids r primary keys, inorder to relate to other tables i ve given id of other as a foreign keys.plzz anybody guide me...

  • 2 Contributors
  • 4 Replies
  • 114 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by palavi

Dani AI

Generated

A short, practical checklist to make the hospital schema safe, flexible and easy to report on, grounded in the thread so far (notes for and reflecting ’s direction).

Separate stable entities from events. Keep demographic/master data (patients, staff/practitioners, departments, rooms) in their own tables. Record every changeable business event—admissions/visits, prescriptions, invoices, payments—as separate transactional tables that reference the masters. That pattern makes reporting, auditing and data integrity much easier than stuffing transactions into person records.

Normalization and keys in plain terms. Enforce 1NF (atomic fields), move repeating groups into child tables for 2NF, and remove derived values for 3NF (store base charge lines, not only an overall total). Prefer simple surrogate integer keys for most tables because they make joins and FKs simpler. Use composite primary keys only when the natural uniqueness is best expressed that way (for small junction tables), or use a surrogate PK plus a unique constraint on the natural key.

Practical modeling and integrity tips. Model invoice line items (one row per service/medicine/room-day) rather than one aggregated charge field. Link invoices to the encounter/admission record so multiple invoices per patient/visit are supported. Enforce foreign keys, use transactions when creating invoice + lines, choose DECIMAL for money with fixed scale, and avoid storing calculated totals unless you have a clear update/locking strategy. Use lookup tables for roles/statuses rather than free text.

Quick resources: a clear, authoritative primer on normalization is available from Microsoft Learn () and the general concepts are summarized on Wikipedia. These will help finish a solid model quickly and produce reliable reports for the project.

Recommended Answers

All 4 Replies

Member Avatar for dickersonka

bill table should not have a primary key of patient
a patient will have multiple bills
that patient should not have a column of pbill, unless it something associated with the patient

move pbill to bill table
then you can have a patient with multiple bills, and i'm not sure why the employee is present, i don't see where you are relating it to anything

Member Avatar for palavi

hi, thank u for replying, k i ll remove pbill, why i ve employee is to get details of other employees like receptionist,nurse,or other workers in hospital. i ve assigned with a hospital management project n submit it in 2 days, shud generate reports of patients,doctors, employees and generate bills, and save transactions made into a database......k can u plz guide me to any tutorials for good database design...explains with examples.. i dont know how to make composite primary keys... n dont know to apply normalisation to DB,i ve only theoritical knowledge... bye thanks

Member Avatar for palavi

Hi,
thanks. i will go thro it..

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.