Methods and design
Database design, falls under the
design phase of the SDLC. With the "traditional" waterfall model, just as with all other aspects of design, the database design would need to be completed in comprehensive detail during this phase, prior to any development which is done in the subsequent implementation phase, as I'm sure you understand already.
When it comes to Agile, things get a lot more flexible. Agile itself is not a method, it's simply a set of values, which several methods comply with. One of the core components of Agile methods in general is iterative development. With iterative development, the system is broken down into smaller pieces, and small selections of these pieces are tackled in "iterations". Each iteration is like a mini software project in its own right. First a little planning is done, then design work, then implementation and testing (can be done together as test driven development (TDD)). The design is allowed to evolve over time. It is in these mini design phases that designs for the database will be created and evolve. The bulk of the design work may end up being done in the design part of the very first iteration, however this design does not need to stay fixed, it can evolve over time through the subsequent iterations.
The idea expressed in the database book that you've been reading, that "database design should be parallel to the software design", fits with the philosophy of Agile software development. With the "traditional" waterfall method, as I already described, the database design would have to be completed before absolutely any implementation work is done, and it should have been done in enough detail, and analysed so thoroughly that absolutely no changes are needed later on. This obviously can waste a hell of a lot of time; it is much easier and much more natural to allow design to be done in parallel to implementation; for it to be allowed to evolve.
Here are two books I recommend:
- Agile Experience design, by Lindsay Ratcliffe and Mark McNeil. This book talks about how design work fits into Agile methods in general. It's technically a web design book, but the essence of it if I remember correct should really apply to any and all design work, and I found it to be a good read.
- Extreme Programming Explained, by Kent Beck (second edition). This book explains XP, a popular Agile method. The author of the book is the creator of the method, and one of the founders of the Agile manifesto. In researching methods for my dissertation I found information on XP on the web to be pretty rubbish; the wikipedia stuff seems to be a mish-mash of things from both the first and second editions of the method/book, and with a lot of other material it's either out of date or difficult to tell or understand clearly. This book really helped me understand it (as it clearly should).
One thing you should understand with XP, is that unlike most (all?) other methods, there are
no "phases". You just have a set of values, principles and practices, and it's down to you to simply use them effectively for any given project.
Database design documents.
Firstly understand that you've got two principle types of databases, relational databases and non-relational databases. Relational databases are
not object oriented.
What documentation you produce can sometimes depend on the SDLC method you're following.
SSADM for example, which I had to follow during part of my university course, explicitly dictates the use of DFD's and ERD's. As another example,
WSDM defines documentation that you must produce, but does not actually define which exact models you use to produce them.
Understand that with Agile methods, a common misconception is that you produce no documentation at all. This is completely false, you produce only what you need to produce, and keep things as simple as you can. If an external client wants/needs a detailed ERD, you produce one and provide updated copies as things evolve. If they don't demand one, you may perhaps decide that you don't need to bother producing one at all. It depends on each unique project.
Something you should be aware of is
UML, which is a standardised modelling language. UML is object oriented. UML can be used for modelling a database, however can have some disadvantages over an ERD. The following might be helpful:
UML as a Data Modeling Notation, Part 1,
Part 2,
Part 3,
Part 4.
"
Class diagram" is probably referring to the UML concept.
Personally I would consider an ERD model to be the standard model to produce. However, I have little experience in database modelling in industry since I'm only just in my last year of university, and up to this point as a student I've always so far simply been told what models to produce, which has always been an ERD and sometimes additionally a DFD.
Normalisation
Normalisation is a set of rules for how to structure a database. In learning normalisation you might go through a normalisation "process", producing a database in 1NF, then 2NF, etc. Once you understand the rules though, from that point on you simply cut straight to it, you don't really think about normalisation, you don't go through a normalisation "process", you simply produce a database that is normalised. So no method or model is going to describe/require the use of normalisation, it's just simply a standard set of rules that you should follow in producing the database model.
I should however point out that in the real world, most if not all databases are never fully normalised. Full normalisation can take things too far and start becoming a problem, for example by making queries unnecessarily complex.
Were you asking whether normalisation fits in with an object oriented database though? If so, then I believe the standard rules of normalisation are specifically for relational databases only. Google "normalization of an object oriented database", e.g.
this.
--
Edit: Search for "erd" in google images for a proper idea of what one looks like if you need to. The one on wikipedia isn't representative of erd's that I have personally produced.
0
which is why i am going through another book as this one seems incomplete to forget such an important topic.
