So, I've finally finished my database design - now I have to justify the design of it. Anyone got any ideas how this would be best done?
i.e. I have followed the steps from the design stage which came from the analysis stage etc.
If it is for coursework/project then the justification is your database design/normalisation along with database dictionary. This would have been your research before actually setting up the database. Which you did first of course....
This is a wishy washy question to be sure. I am going to make an assumption that you've been asked to justify the design of the database as part of an evaluation of the work you've just done, if so here's some questions you should ask yourself.
If it's unnormalised, why is it unnormalised (i.e. flat) will there be a definite advantage over other methods in doing so? If you've normalised it, why have you normalised it in the way that you have? How much data is written to the database, is there any redundancy or replication of data elsewhere in the database?
Could it be optimised any more? What about if you were storing several billion entries, is your database fast enough to account for it? Does it need to? What if you needed to upgrade it in the future? Can it roll into a distributed system relatively easy? What are the needs of your client/system and does the database meet these needs? This is the kicker question when it comes to justifying your design.
It's for college - the database is a Video Store kind of one allowing enrolling of members and loaning of DVD's etc.
I've done ALL the design work, normalisation and things like that. I just don't know what to put. Do I actually write "This database is fine because I followed the design which came from the analysis which came from the customer"???
thats the exact database design i did at college
we then had to take it a step furthur and write an ASP interface for the frontend
There are currently 1 users browsing this thread. (0 members and 1 guests)