"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.
