С точки зрения работы с базами даннных, проблема становится актуальной в нескольких случаях. Первый очевиден: как только работать с информацией начинает больше, чем один человек. Второй обычно связан с желанием закрыть информацию от посторонних глаз. Сравнительно новым можно считать защиту персональных данных, определяемую законодательством
Важность темы определяется тем, что она должна предусматриваться и разрабатываться уже на первом этапе построения БД.
Сразу договоримся, что, как и любой вопрос, связанный с защитой, разграничение прав доступа не может иметь однозначно идеального решения. А речь идет именно о защите, пускай в первую очередь от непреднамеренной порчи информации.
Некоторый парадокс состоит в том, что любые права в итоге будут реализовываться программно. Администрирование прав (коже, кстати, право) должно осуществляться удобно и является естественной функцией крупной системы. Важно, чтобы Гибкость просмотр, редактирование (в т.ч. удаление и добавление), Право добавления записей обязано рассматриваться как важнейшее. В качестве примера возьмем названия компаний. Нерадивый (или просто плохо обученный) оператор совершенно элементарно может ввести несколько "одинаковых" названий, различающихся единичными символами. Решить проблему программно невозможно Фиксация действий Контрольный код Шифрование паролей (обратимое и необратимое) Шифрование данных
Значительная часть СУБД не имеет встроенных возможностей шифрования и/или парольной защиты данных, что обусловливает их потенциальную кражу в файл-серверной и локальной версии хранения. Кража может иметь смысл не только в качестве источника получения информации, но и для изучения ее построения. В последующем возможно несанкционированное изменение.
Таблица пользователей
| Наименование | Поле | Примечание | Комментарий |
| user_id | I(1-4) | Код пользователя | Размер поля может изменяться в достаточно широком диапазоне в зависимости от назначения БД |
| user_name | C(??) | Имя пользователя | |
| password | I/C | Пароль | Имеет смысл только хранение в необратимо зашифрованном виде |
| pos_id | I(4) | Должность | |
| user_main_id | I(1-4) | Код пользователя в главной таблице людей |
В ряде случаев подобную таблицу можно связать или основывать на уже имеющемся перечне людей (кадры, бухгалтерия, клиенты). Здесь для этой цели введено поле user_main_id.
Таблица прав
| Наименование | Поле | Примечание | Комментарий |
| user_id | I(1-4) | Код | |
| r1 | L(1) | Право 1 (есть или нет) | |
| r2 | L(1) | Право 2... | |
| ... | L(1) |
Для предотвращения редактирования прав из внешней программы можно ввести дополнительное поле, сохраняющее в зашифрованном виде контрольную сумму всех полей, а проверку производить при каждом обращении к праву. Это отнимет минимум ресурсов при максимальной безопасности.
Нарушение правил нормализации неочевидно, так как поля всегда хранят информацию (истину или ложь).
Естественно, что разобраться с большим списком прав будет сложно даже для разработчика.
Поэтому организуем сервисную таблицу-справочник, которая может и не хранится с остальными файлами, а находиться в его системной папке.
Таблица пояснений к правам
| Наименование | Поле | Примечание | Комментарий |
| r_id | I(2) | Код права | Поиск путем вычленения номера из имени поля таблицы прав |
| r_name | C(40) | Наименование | |
| r_descr | M(10) | Описание | Поле ценно тем, что может содержать как пояснения, так и задумки для последующей реализации. Все равно оно никому недоступно |
Пункты 1–3 уже создают несколько десятков, а то и сотен прав. В принципе понятно, что в обычную таблицу БД такой объем вставить нельзя. Но не сразу становится очевидным решение.
Таблица
| Наименование | Поле | Примечание | Комментарий |
| user_id | I(1-4) | Код пользователя | Размер поля может изменяться в достаточно широком диапазоне в зависимости от назначения БД |
| r_id | I(2) | Код права |
Если в таблице будет найдено право с соответствующим номером, то оно у пользователя есть. В предыдущем примере 100 прав займут 100 байт, а здесь (по максимуму) – 600 байт (6*100 записей), но обычно большинству предоставляется существенно меньше прав и объем хранения будет примерно одинаков. При расширении списка в соответствии со сказанным выше, выгода от такой технологии станет существенной как по объему, так и по скорости и удобству.
Кроме того, мы можем добавить еще одно поле, означающее уровень права и сделать систему гораздо более сложной и гибкой. В предыдущем примере надо было бы делать поле права не логическим, а числовым.
Таблица
| Наименование | Поле | Примечание | Комментарий |
| _id | I(4) | Код | |