Здравствуйте, Ram!
Rules - правила. Типа ограничений на вводимую информацию в БД. Roles - роли. Это для того чтобы объединять пользователей SQL сервера в роли чтобы было легче администрировать БД. Views - представления. Представление - это отдельная выборка из базы данных (возможно из нескольких связанных таблиц) по каким-то определённым критериям.
К сожалению примеры дать не могу, так как нет SQL сервера под рукой. А вообще для таких вопросов существует специальная (моя) рассылка MSSQL Server 2000/2005. Это просто на будущее, чтобы вопросы не перемешивались.

Здравствуйте, Ram!
Вот как определяет SQL Server Rules Microsoft:
Rule:

A database object that is bound to columns or user-defined datatypes and specifies which data values are acceptable in a column. CHECK constraints provide the same functionality and are preferred because they are in the SQL-92 standard.

Иными словами, правило обычно привязано к колонке таблицы илипользовательскому типу данных и определяет приемлемые значения для данной колонки в таблице. Тот же эффект достигается с помощью ограничений CHECK, использование которого является предпочтительным, поскольку соответствует стандарту SQL-92.

Роль:
Используется для определения привилегий пользователя БД, например у Администратора БД привилегий больше, чем у обычного пользователя. Привилегии определяются через роль пользователя.
Роли подразделяются на: Server Roles, Database Roles, Application Roles.

View:
Является отображением всех или части данных содержащихся в одной или более таблицах - в зависимости от того, что Вы хотите, чтоб видел конкретный пользователь с конкретными привилегиями.

Удачи!

Здравствуйте, Ram!

Ко всему, что сказано выше, добавлю своё мнение о представлениях (VIEW) данных. Их в самом деле можно использовать для разграничения прав доступа, но я чаще пользуюсь ими для сбора информации из разных таблиц базы данных. В само представление могут быть зашиты очень сложные запросы, объединяющие несколько таблиц в одно целое, а также определения вычисляемых полей (например, я формировал вычисление возраста человека по дате его рождения и текущей дате и определял результат как отдельный столбец). Приложение видит VIEW как отдельную таблицу, и если не нужна дополнительная фильтрация, оно может обратиться к представлению примерно так:

SELECT <список полей>
FROM <название_представления>

Можно, как и в случае с обычными таблицами, написать дополнительные критерии отбора:

WHERE <перечень условий>

Представления, как и таблицы, можно также объединять с другими представлениями и таблицами в SELECT-запросах и использовать в качестве основы для других представлений. Впрочем, если пишется сложный VIEW, то как правило он базируется на физических таблицах (из соображений эффективности, но это не более чем рекомендация, к которой Вы вольны прислушаться или проигнорировать её) и включает в себя всю необходимую информацию, чтобы приложению не было необходимости цеплять к нему дополнительные таблицы (тоже рекомендация, а не правило, к тому же представления бывают совершенно разными и по сложности, и по цели создания).

Если в Вашей базе данных существует сложная логическая связь между разными таблицами, которой Вы предполагаете часто пользоваться, имеет смысл оформить эту связь в "физическую" структуру при помощи представления: это упростит обращение к нужной информации. Если нужна более детальная консультация, пишите в личную почту.