Как менеджер Business Intelligence, мы полагаемся на схему для логической группировки и управления безопасностью. Вот несколько примеров того, как мы используем схему:
ЛОГИЧЕСКАЯ ОРГАНИЗАЦИЯ
У нас есть общая база данных, которая загружается пакетами служб SSIS исключительно для подготовки данных перед загрузкой нашего оперативного хранилища данных (ODS). В этой базе данных, за исключением схемы, все объекты имеют идентичную структуру (имена таблиц, имена столбцов, типы данных, обнуляемость и т. Д.) От своего исходного источника. Мы используем схему для указания исходной исходной системы таблицы. В некоторых редких случаях две разные базы данных имеют таблицы с одинаковым именем, и схема позволяет нам продолжать использовать исходное имя в промежуточной базе данных.
В каждой базе данных на наших BI-серверах каждый член команды имеет схему test_username. Когда мы создаем тестовые объекты в базе данных, это позволяет легко отслеживать, кто создал объект. Это также значительно облегчает последующую очистку тестовых объектов, поскольку все знают, кто что сделал. Честно говоря, просто зная, что мы сделали это, обычно достаточно знать, что его можно безопасно удалить, особенно когда мы не можем вспомнить, когда и почему мы сделали это!
В нашей базе данных контроллера данных мы используем схему для разделения процессов различных типов между отчетами, etl и общими ресурсами.
В нашем хранилище данных звездной схемы все объекты делятся на схемы измерений и фактов.
Когда мы отправляем данные на другие серверы департаментов, мы заставляем все объекты BI на их серверах использовать схему bi. Это позволяет ДЕЙСТВИТЕЛЬНО легко знать, что bi загружается и поддерживает таблицу, даже если ее нет на нашем сервере. Если целевой сервер не является сервером SQL Server 2008/2005, то перед таблицей добавляется префикс bi _.
Когда дело доходит до этого, мы используем схему для логической организации каждый раз, когда добавляем префикс или суффикс к объекту, чтобы помочь организовать его в отсутствие схемы. Сказав это, есть несколько случаев, когда мы не используем схемы на наших BI-серверах. В нашем WorkingDB все dbo. Наша WorkingDB используется как TempDB для создания временных таблиц, но эти таблицы являются временными таблицами, которые, как мы знаем, мы будем создавать при каждом запуске процесса ETL. Особое свойство WorkingDB заключается в том, что мы никогда не выполняем резервное копирование базы данных, и все процессы ETL, использующие базу данных, должны быть в состоянии воссоздать свои объекты с нуля при отсутствии таблицы. В этом случае мы чувствовали, что использование схемы не добавило ЛЮБОЙ организационной ценности, поскольку мы фактически не используем объекты вне их временного процесса ETL.
БЕЗОПАСНОСТЬ
Поскольку мы являемся группой BI, мы обычно не создаем и не поддерживаем наши собственные приложения. Мы почти исключительно используем чужие приложения и переносим данные из их внутренних баз данных на наш сервер. Тем не менее, у нас есть одна база данных с именем bi_applications, которая является серверной для множества небольших приложений CRUD. Эти приложения, как правило, представляют собой формы ввода данных, которые мы предоставляем бизнесу, чтобы они могли собирать данные, которые в противном случае нам пришлось бы поддерживать в BI. Это способ передачи данных, которые должны быть в производственных приложениях, в BI, в то время как мы ждем, пока наши усовершенствования приложений с низким приоритетом соберут пыль в будущих списках разработки. Каждое приложение имеет отдельную схему, а учетная запись приложения, используемая для обновления базовых таблиц, имеет ТОЛЬКО доступ к объектам связанной схемы. Это позволяет легко понять, защитить и поддерживать отдельные приложения.
В некоторых случаях я предоставлял опытным пользователям прямой доступ к нашим таблицам или хранимым процедурам в базе данных. Мы полагаемся на использование схемы в сочетании с ролями для защиты объектов. Мы предоставляем разрешения для схемы, а пользователи добавляются в роли. Это позволяет нам легко понять, какие объекты используются кем, без необходимости разбираться в ролях, чтобы выяснить это.
Короче говоря, мы используем схему в целях безопасности, когда мы, вероятно, рассмотрели бы возможность разделения объектов на их собственные базы данных и когда мы ожидаем, что приложение или пользователь вне BI получит доступ к нашим базам данных.
Хотя это не лучшие бизнес-практики для разработчиков приложений, я надеюсь, что мои би-сценарии использования могут помочь вам подумать о некоторых способах использования схемы в вашем бизнесе.