Forum OpenACS Q&A: DATA MODELS in the Design document

Posted by Ayman M on 08/17/02 04:34 AM

Hi all,

As you may have previously read, I am planning on developing a
WebMail system (client) for my thesis project under Rafael Calvo.

I am currently creating my Design document and I am not sure exactly
how to make the DATA MODEL. I read the 'Detailed Design Documentation
Template' in the 'Chapter 6. Engineering Standards' however I'm still
unsure how to tackle it and develop my data model.

I understand it related to sql statements and how the tables will be
set up but im still a bit vague on how to attack it and develop these
models. Any help would be appreciated.

Thanks in advance.

2: Response to DATA MODELS in the Design document (response to 1)

Posted by Roberto Mello on 08/17/02 05:10 PM

Ayman,

Please refrain from using fully capitalized words. They are just plain ugly and frowned upon on e-mail communication, since they mean that you are screaming.

The documentation you should read is the OpenACS Developer's Guide (http://dev.openacs.org/doc/dev-guide.html), more especifically "OpenACS 4.5 Data Models and the Object System" (http://dev.openacs.org/doc/objects.html).

Quoting from that chapter in the documentation: "Developing data models in OpenACS 4.5 is much like developing data models for OpenACS 3, save for the implementation. As usual, you need to examine how to model the information that the application must store and manipulate, and define a suitable set of SQL tables."

Teaching how to model data in a relational database should be addressed in more detail in the documentation (I'll personally tackle this) with links to more appropriate sources of information, but it's beyond the scope of the OpenACS documentation.

There are several books on data modeling out there. I'd suggest you start with "An Introduction to Database Systems" by C.J. Date. Date's book is very good.

Then you should learn some SQL. Most SQL books are way lengthier than they should be. I like Philip Greenspun's "SQL For Web Nerds" (http://philip.greenspun.com/sql/). This will give you a good introduction to SQL.

The OpenACS has thousands of lines of SQL code that you can look at to learn more. After you feel pretty confident about your SQL skills, you should read "SQL For Smarties" by Joe Celko. Excellent book.

Most people wanting to "learn databases" think that they should get straight into SQL (bypassing the learning the relational model and some of its theory - C.J. Date's book) . This is a serious mistake IMHO, and leads to the aberrations that you so often see around in database applications and also explains why so many people think MySQL is better than real relational databases.

3: Response to DATA MODELS in the Design document (response to 1)

Posted by Roberto Mello on 08/17/02 05:47 PM

I should note that Wrox Press' "Beginning Databases with PostgreSQL" is also a good book for learning SQL, despite its bad editing (several typos and grammar errors were left, but the book is good if you ignore those.

4: Response to Data Models in the Design document (response to 1)

Posted by Ayman M on 08/18/02 01:20 PM

Thanks Roberto for your guidance. It is much appreciated.

Maybe its due to my limited experience with Data Models but are we meant to be able to know about all tables, 'package' and 'package body', etc before we start coding?

Also, ive seen some API's in other Design documents. Are we meant to complete all these functions before we start coding or is the API made after completion of coding?

Thanks

PS: My apologies for the CAPS

5: Response to DATA MODELS in the Design document (response to 1)

Posted by Roberto Mello on 08/19/02 07:10 AM

"Maybe its due to my limited experience with Data Models but are we meant to be able to know about all tables, 'package' and 'package body', etc before we start coding?"
Designing a data model has to do with thinking about all the data that you're trying to represent, first in a very abstract way, then working gradually to refine that model, foreseeing areas that will possibly be extended, etc.
It sounds difficult, but really it's just a matter of learning to think relationally (at least it has been for me. I don't even have to think about the different normal forms anymore, they just come out naturally). Practice is the key, as usual.
For example, you'd start with something like this: "I'm trying to store information about people and e-mail addresses". <scribble "People" and "addresses" in a piece of paper, in two separate columns>
"What do I need to store about people?" <write it under the "People" columns>
"What do I need to store about addresses?" <write it under "addresses">
And so on. Using your knowledge of the relational model, eventually you should end up with several columns each with several things that they will store.
From there on, you pretty much have tables. This is just one simple way to do things. You can spend a lot more time and be a lot more detailed if you want. You can use fancy graphical tools to do the work for you (usually doing a worse job and taking more time). If you are expanding on an object-oriented program/design, you might want to model things in UML. etc, etc, ad infinitum.
But the paper approach that I described above works pretty well for a good number of things.
"Also, ive seen some API's in other Design documents. Are we meant to complete all these functions before we start coding or is the API made after completion of coding?"
This is up to you. It depends on how you do your software design. It's a good idea to write down the requirements for the software you're going to write, and also write the spec for the API and such.
It's usually not a very good idea to just start coding and coming up with what you're trying to do on your head while you're doing it. It just doesn't work well unless it's something pretty simple.
More info on your favorite software engineering book.

6: Response to DATA MODELS in the Design document (response to 1)

Posted by Roberto Mello on 08/19/02 04:52 PM

Hmph. I wrote several things in tags for my last post (things like <scribble in paper>) and they seem to have been chomped. Oh well, should've seen that one coming.