70-442: Conceptual Data Modeling (LD, 3)

From Chapter 3 of “Pro SQL Server 2005 Database Design and Optimization”, by Louis Davidson (LD).

So this is about understanding requirements (and the old “what the user does not know they want” conondrum and other related problems). Been involved with this kind of work plenty of times and very interesting to hear what and old dog like LD has to say about it.

LD mentions tools like UMN, Visio and MS Solutions Framework. However also states that spreadsheets do quite a good job for just gathering and tracking requrements. Not sure I agree, if you are just going to list stuff do it online in a portal of some sorts. As for his database models he sticks to IDEF1X.


Documenting the Process

LG points out the importance of recording and maintaining information about the process and decicions made. Many good reasons why this is a good idea. Looking back at projects I have been involved with I think this was often very much lacking and I think tools like Zoho projects would be very usefu as public facing and so allows the users/clients to be directely involved and kept up to date.


Requirements Gathering

So this is where we have the wonderful world of client interview/meetings, existing systems (beware) and whatever else might be brought to the table.


Identifying Objects and Processes

Entities generally represent people, places, objects, ideas, or things referred to grammatically as nouns. Other less obvious candidates are things like Events, Documents (Records, Journals). You will also have some system specific entities like Audit Trails etc, but these do not belong in a conceptual model.

Relationships between Entities – here we have of course the one-to-N and many-to-many. LD goes through how you can extract these from reading a specification, don’t think we need the details of this here.

Identifying Attributes and Domains – again you LD goes through how to pinpoint these – quickly the main things to look out for are: Identifiers (NI Numbers, Licence Registration, Serial No – note that these will not neccesarily make keys). Descriptive Information – not surprisingly, Locators, Related Information and Values. Really I think this is beyond what can be taught – most will be obvious and the rest will come from either trial and error or experience.

Identifying Business Rules and Processes – there is of course no straightforward or easy way of making sure you have all the business rules, gererally look out for words like “must”, “will”, “occur”, “have to”. Again – you will probably know. Really I think the key thing here is actively engaging the client beyond just the bare minimum “we want this and that” discussion, or “it used to do such and such”. Again – most times the client’s final goal is often vaguely defined as “making x easier” or “improving y ” and “cutting z”. Ironing out the specifics of what needs to be built is a collaborative process, and the first step for the systems designer (which often times ends up meaning us, the developers) is to get to know your clients business and field if not completely then very, very well!

Finally DL correctly points out that the above very often if not always is an iterative process. It takes more than just one client meeting.


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: