Что-то вроде этого?
User table
----------
ID (primary key)
Username
(more columns with more user info)
Album table
-----------
ID (primary key)
AlbumName
(more columns with more album info)
OwnerID (foreign key to User.ID)
AlbumPermission table
---------------------
ID (primary key)
AlbumID (foreign key to Album.ID)
UserID (foreign key to User.ID)
(more columns indicating permissions)
С этим макетом у вас есть пользователи и альбомы в качестве сущностей и таблица, связывающая их (таблица связи многие-ко-многим), которая содержит разрешения.(Эта таблица также является своего рода мета-сущностью. Сама по себе она по сути бессмысленна, но в контексте пользователя или альбома она содержит информацию об альбомах, к которым пользователь имеет доступ, или о пользователях, которые могут получить доступ к этому альбому.)
Каждый Альбом имеет одного пользователя в качестве владельца и ноль или более пользователей, связанных в таблице AlbumPermission, с которыми связаны различные разрешения.
Редактировать:
Исходя из вашего комментария относительно многоуровневых пользователей, возможно, что-то вроде этого ...
Client table
------------
ID (primary key)
ClientName
(more columns with more client info)
User table
----------
ID (primary key)
ClientID (foreign key to Client.ID)
IsAdmin (boolean)
Username
(more columns with more user info)
Album table
-----------
ID (primary key)
AlbumName
(more columns with more album info)
OwnerID (foreign key to User.ID)
AlbumPermission table
---------------------
ID (primary key)
AlbumID (foreign key to Album.ID)
UserID (foreign key to User.ID)
(more columns indicating permissions)
Разница здесь заключается в добавлении таблицы Client, в которую группируются записи пользователя.У записей пользователя теперь есть внешний ключ к записи клиента, так что каждый пользователь является участником ровно одного клиента (клиент-пользователь - один-ко-многим) и поле IsAdmin, указывающее, является ли этот пользователь пользователем административного уровня.для этого Клиента (то есть имеет возможность создавать / изменять записи Пользователя для Клиента).
Ожидается, что у каждого Клиента будет по крайней мере один пользователь.* Не обязательно нужен один в этом дизайне, но имеет смысл создать начальную запись пользователя при создании клиента (пользователя, который регистрирует клиента).
Вы можетерасширите это еще больше, добавив более динамические разрешения для записей о клиентах и пользователях, но это должно быть достаточно простым, чтобы начать работу.