Jump to content
|Topic||Stats||Last action by|
|Your Black Friday deals||
|Is there a software which can share the video over wifi?||
|[PC Gaming] Giveaway: Mirror's Edge, possibly more to come.||
|Interstellar and Guardians of the Galaxy||
|Wondershare Video Converter Ultimate 188.8.131.52||
Posted 23 November 2012 - 01:07
Posted 24 November 2012 - 03:10
Posted 24 November 2012 - 23:24
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:
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.
- 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).
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 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.
Posted 24 November 2012 - 23:53
Posted 25 November 2012 - 01:57
So basically I will be designing software in Visual studio (visual c#). An object oriented language. Now when it comes to designing the database I will probably develop some diagram in UML format as you have mentioned it is object oriented.
What does the design process involve for object oriented databases? Does it involve analysis of the business first (understand how the business operates, it's key objects and different business processes and things like that?) Basically do I base the database design on a set of facts or a description of the business and so develop a UML based diagram based on the facts? So I should first understand the nature of the business? (interview employee's etc)
Is there a set procedure I should be following like a series of steps when designing the database? Or can I just jump straight into making a UML based diagram? Also is one UML diagram sufficient as a database design which can then be implemented and created?
I found this process on the web for designing simple databases, can this process be used for object oriented databases?
What about the database technology offered in Visual c# is that relational or object oriented? And do we query it with SQL?
Can I develop relational databases in visual c#? I am reading a book on Visual c# and object oriented concepts and nowhere does it talk about designing a database. The closest thing it relates to a database is a class diagram which includes attributes, object names and behaviors or methods. Is it the case that a UML diagram is essentially the design of a database? It also talks about sequence and activity diagrams. (strangely it doesn't mention anything about testing which is why i am going through another book as this one seems incomplete to forget such an important topic.
Posted 27 November 2012 - 10:42
Posted 28 November 2012 - 06:12
Posted 28 November 2012 - 23:56
Firstly, use a relational database, not an OO one. As I said earlier, I don't recognise even a single product name out of the OO ones listed in the link above and my impression is that they are rarely used. Using a relational database you should therefore create an ERD, not a UML diagram for the database.
Posted 30 November 2012 - 00:13
Secondly, and most important of all, Keep things simple!
- In creating design documents/models, only create whatever will help you, give you what you need and nothing more.
- Create your diagrams free-hand. Don't waste time trying to use a software package to produce something "neat".
Posted 06 December 2012 - 23:36