I was learning SQLite3 from here; it's really good and portable, but what if someone somehow get to know the database file name say test.db, and then simply downloads it ?
Probably it will be more dangerous than SQL injection, as the attacker can easily get an copy of whole database.
You can restrict .db files in your .htaccess file to do the same add this lines of code in your .htaccess file located in root
<Files ~ "\.db$">
Order allow,deny
Deny from all
</Files>
This will result in an 403 error and will also hide it from being listed in the files list if you (probably you wont) put an index file in an directory.
Just don't keep the data file in a directory that is accessible over HTTP.
If you were using Postgresql or MySQL, you wouldn't keep the data files they used under your web root. The only relevant difference is that databases built around servers tend not to ask you where they should store their data files each time you create a new database (and just stick them somewhere in /var/ based on their default configuration). Don't keep the SQLite files public either.
The question of whether giving people an entire copies of the database is more dangerous than SQL injection is debatable. On the one hand, they get very easy access to all the data, but on the other, they can't change anything on your website.
This question is a consequence of the ubiquity of shared hosting: there is a common view that everything in a project has to go in the web server's document root. However, where possible, it is much better to have a sub-folder in the project for the document root, such as www. You then set up a custom vhost to point to this folder within your project.
That means you are free to create folders elsewhere in the project for files that simply must not be downloadable. I tend to create a folder called /data for SQLite databases.
Unfortunately, not all hosts permit this, in which case @Subhanker's .htaccess approach is a nice solution.