I am designing a back end database that will handle registration and login. I need to be able to deal with different account and authentication types.
The main issue here, that is different from other database design for user login is that a user could have a password to log in, a smart card, both or a combination of other, and I am unsure about null values etc.
Imagine a user registers their company online (on my website), the company details go into my company table, and their details go into my user table.
They then get the "account type" as company administrator (account type table).
That user (company administrator) can now log into their company account online, and register multiple users (in their company).
The issues I have are below, and hopefully my design solves these but I am not sure if I am on the right track.
Each user could have either a password, or a smart card to log in. I have the relationship for password and smart card tables but this means there will be many null objects. Either a user will have a password or a smart card.
Just to clarify my needs. When a user registers the company, they become a company administrator, but they could also set up other administrators and/or users, so that why I have them all in different tables.
I have added further tables as each user must have one or more forms of ID checked, along with being provided one or more access codes that will provide a range of access levels (physical and computer resource based)
I am mainly concerned that I have the right type of database normalization AND relationship design.
Lastly, the Smart Card table will have multiple smart card entries that I create, and I need to be able to assign 1 or more to a company, then, the company administrator can assign one or more of these to a user belonging to that company.
Are my relations OK for this? What about null values until I have the smart cards assigned, is this OK? Any help and guidance would be great.