Your question made me think that you're starting your game with the DB design, and this seems to be the case. Now you basically have some tables and you want to add more "stuff".
Let me say that starting with the DB is a very bad idea. Firstly it doesn't represent a game-world properly and is not suited for lots of changes. Let's assume that you have a nice and normalized DB design and you notice that you'll have to change things because you want to add "feature X". That might force you to re-do the entire architecture.
I suggest you start the other way round. Define what your game should do. Write it down. If you're eager to start coding, then write some code that works with values from a text-file or hard-coded values. Once you figure out what you need and how things play together, you can plug the DB into that.
The DB isn't your game, it's just a data-storage. Your game should be written in a way that this storage is abstracted so that you can start with some simple (hard-coded) values and later plug in the code that actually does the DB connection etc. Also things like the "login" (eg. username, password etc.) is really not something you need right off the bat.