User permission hierarchy in DB - sql

Question

I am trying to add a permission hierarchy for users e.g. child, parent, admin
My idea is to create a generic user table with usernames and passwords and accessibility which would be from 0 to 2 , 0 - child 1 - parent 2 - admin, but I do not know how to connect the user table to parent/child table since they have different variables.
Access picture of my database right now
To be clear parent/child wouldn't have username/password like in this picture anymore with user table.
Update:
DB using only one table for users
This table would keep the fields that are only for parents empty if this is a child etc. I would want feedback if the variable 'accessibility' makes sense that would be value from 0 to 2 which would allow me in code to check if it is a parent child or admin

Answer 1

What you want is a kind-of table inheritance that prevents two derived entities from sharing the same supertype instance.
Databases like Access and MS SQL Server do not support table-inheritance like how PostgreSQL does, but you can fake it:
TABLE Users (
UserId int PRIMARY KEY IDENTITY(1,1),
UserName nvarchar(50) NOT NULL,
PasswordHash binary(32) NOT NULL, -- assuming sha256
PasswordSalt binary(8) NOT NULL
)
TABLE Parents (
UserId int NOT NULL PRIMARY KEY,
-- insert parent-specific fields here
FOREIGN KEY UserId REFERENCES Users ( UserId )
)
TABLE Children (
UserId int NOT NULL PRIMARY KEY,
-- insert child-specific fields here
FOREIGN KEY UserId REFERENCES Users ( UserId )
)
This schema means that a Parent or Children entity cannot exist without a single specific User entity also existing. However because Access does not support true table-inheritance it cannot easily constrain UserId values such that only 1 Parent or Children row can have that value (i.e. there can be a Parent AND a Child that share the same UserId value).
Fortunately there's a hack that is mathematically correct (as far as relational-algebra is concerned) but which unfortunately breaks aspects of OOP in that the superclass (User) is now aware of it subclasses - but this might be desirable is certain circumstances...
...anyway. the trick is to add an enum value to User's primary key (so it's a composite-key) which identifies a singular subclass, then add a constant (enforced via CHECK CONSTRAINT) composite-key component to match in each "derived" table, like so (using pseudo-SQL - the relational-algebra is portable, but concepts like enums and check-constraints don't necessarily port to MS Access very well):
ENUM UserType ( HumanParent = 1, HumanChild = 2, Other = 3 )
TABLE Users (
UserId int IDENTITY(1,1),
UserType UserType NOT NULL,
UserName nvarchar(50) NOT NULL,
PasswordHash binary(32) NOT NULL, -- assuming sha256
PasswordSalt binary(8) NOT NULL
PRIMARY KEY ( UserId, UserType )
)
TABLE Parents (
UserId int NOT NULL,
UserType UserType NOT NULL,
-- insert parent-specific fields here
PRIMARY KEY ( UserId, UserType )
FOREIGN KEY ( UserId, UserType ) REFERENCES Users ( UserId, UserType )
CHECK CONSTRAINT UserType = 1
)
TABLE Children (
UserId int NOT NULL,
UserType UserType NOT NULL,
-- insert child-specific fields here
PRIMARY KEY ( UserId, UserType )
FOREIGN KEY ( UserId, UserType ) REFERENCES Users ( UserId, UserType )
CHECK CONSTRAINT UserType = 2
)
So at the cost of slight inefficiency (i.e. the extra storage needed for the UserType columns - and computational expense of evaluating the CHECK constraints) you gain guarantees of the correctness of your data.
Now have fun porting that to Access :)