Totti, I totally agree with Alex: Until you have more details, it's rather like asking a building contractor to estimate the square footage of a house if you know the number of bedrooms there will be. Ken Behring's 4 bedroom home is 30,000 square feet; my 6-bedroom home is only about 2,200 square feet. So it obviously depends.
Given the "it-depends" disclaimer, we can suggest some sort of estimates once we obtain answers to some preliminary questions:
1) who is asking for the estimate?
2) why do they want to know? (Is it for preliminary hardware-cost estimate, et cetera?)
3) how close to "actual" do they expect your "estimate" to be?
4) what are the business risks (including your job) if your estimate is off by +/- 10%? 50%? 100%? 1000%?
5) what applications, current and future, will reside on the database?
6) what growth factors do you expect for the applications?
7) what is the size of the database(s) that house those applications currently? (Either in-house or comparable figures from industrial publications, users' groups, competitors, et cetera might help.)
Armed with answers to those preliminary questions, you can start modelling some size estimates.
I would avoid the "estimating game" if the ones wanting the estimates are unable to provide details. Whenever I find myself in that position, I respond, "Without additional details, I estimate the database will be 100GB, +/- 80GB." Usually they get the idea.
You mentioned you know the number of rows (one dimension) with which you will be dealing. If you don't yet know the second dimension, the attributes (columns), and their average sizes, then it would be like asking the area of a trapezoid, given the length of one side.
Once you know the attributes (with their average sizes), we can then contribute more to your solution.
Cheers,
Dave