January 6, 2012 at 7:03 am
I am designing a database for fee registration system. but I can not figure out the database design for this system.
My queries are:
1. list out the names of the students who have not cleared their fee for a particular month.
eg. A, B, C ,D have not cleared their fee for the month of January
2. list out the names of the months for which the fee is unpaid by a particular month
eg. student A has not cleared his fee for the month of Jan, March and October
What can be the tables for this sytem:
STUDENT ,
FEE
or I've to add an additional table
MONTH
What is the relationship b/n the tables developed for the system?
The user input for the system is:
Student Name :............
Student Roll No. :............
Fee for the month of :...........
Amount ($) :................
January 6, 2012 at 7:13 am
You must understand the basic normalization concepts to create the database. As far as my understanding of normalization (as per Codd:- key,only the key and nothing but the key) I would not make FEE and month as tables but as an attribute for an table say Student, where in I can get the required information based on my StudentId Key.
So,to design a database you must first take into consideration the normalization and basic design concepts for your system.
January 6, 2012 at 7:36 am
This looks like homework - isn't it?
I would agree with Arun in regards to data normalization but I would say that you have to move back one step and design a proper ER Model, once you have a sound ER Model most of your tables (including attributes) and relationships will become apparent.
So... think about what are the "Entities" of your model and what are the "Relationships" between such "Entities".
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.January 26, 2012 at 6:36 am
Can I just add a note. Never, ever, design a database based off what the queries will be. Queries change. They get added, they get removed, they get entirely redesigned. Designing for queries is the road to madness.
Step back, look at what information will be stored, do the ERD design (model your database), find the relationship between the entities (student, address, teacher, class, etc.), discover your keys (primary and foreign) that connects these entities, then build out your logical tables. Once you have the logical, the physical falls into place pretty quickly. Then you have your answer.
January 26, 2012 at 7:07 am
Never, ever, design a database based off what the queries will be.
It’s very well suited on OLTP design. However I would differ in opinion for OLAP / DW designs.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply