Использование утилиты ManagementStudio. ОкноSolution Explorer. Введение в шаблоны.

Основной интерфейс работы с SQL Server реализован с помощью утилиты Management Studio. Она вобрала в себя мощный набор инструментов, подобный Visual Studio, позволяющий разработчикам и администраторам баз данных создавать проекты баз данных и управлять СУБД SQL Server 2005 с помощью графического интерфейса пользователя либо с помощью инструкций Т-SQL.

Утилита Management Studio явилась результатом естественной эволюции предыдущей версии SQL Server (Enterprise Manager и Query Analyser) 2005, которые она заменила. Инструменты Object Explorer и Query Editor унаследовали удобства своих предшественников, одновременно вобрав в себя гибкость Visual Studio. Утилита Management Studio имеет обратную совместимость с предыдущими версиями сервера (SQL Server 2000 и частью SQL Server 7), так что ее можно использовать в смешанной среде.

Management Studio является всего лишь инструментом, позволяющим управлять сервером и создавать базы данных. Подобно любому другому клиентскому приложению, она посылает команды Т-SQL на сервер или использует специальные объекты управления сервером (SMO),также она инспектирует сервер и отображает в понятном представлении его объекты и конфигурацию. Важным элементом организации работы в многосерверной среде является возможность подключения ко множеству экземпляров SQL Server.

Окно Solution Explorer — это основное окно для работы с отдельными компонентами создаваемого приложения. Оно по умолчанию отображается в правом верхнем углу SQL Server Management Studio. В окне Solution Explorer отображается в виде древоподобной структуры набор используемых объектов, соединений и запросов к базе данных. Все это составляет проект, над которым ведется работа. Корневой элемент дерева носит название решения. По умолчанию ему присваивается значение Solution 1, однако разработчик может изменить это имя на любое другое, используя окно свойств решения. Далее в виде ветвей дерева отображаются текущие проекты. Решение может включать в свой состав один или несколько проектов. При этом объекты, выступающие в качестве листьев дерева, могут быть связаны с одним из проектов или напрямую с решением. Листья обычно представляют собой файлы, которые могут содержать информацию не только об определенном объекте, но и о целом классе подобных объектов. Утилита SQL Server Management Studio поддерживает несколько различных типов проектов:

• SQL Server Scripts — этот тип проекта используется для того, чтобы выполнить логическую группировку сценариев T-SQL и соединений к базе данных. Наиболее важным применением данного типа проекта также видится возможность выполнения группировки DDL-сценариев;
• SQL Mobile Scripts — данный тип проекта используется для группировки запросов и соединений для баз данных на основе SQL Server CE Edition;
• Analysis Server Scripts — данный тип проекта используется для логической группировки сценариев T-SQL, созданных для обработки сервером аналитики. Также может содержать MDX- и XMLA-сценарии.

Введение в шаблоны

Шаблоны утилиты Management Studio являются стартовой точкой при создании новых типов кода, обеспечивая целостность программ. Управление шаблонами выполняется в окне Template Explorer. Для использования шаблона следует создать новое окно редактора запросов, указав данный шаблон.

Шаблоны хранят сценарии SQL в структуре папок. Это значит, что можно без труда создавать собственные шаблоны и менять уже существующие. Папка для хранения шаблонов задаётся во вкладке General диалогового окна Options. Это позволит нескольким разработчикам совместно использовать общий набор шаблонов, размещённый на каком-либо сетевом устройстве.

Реализация физической схемы базы данных. Проектирование физической схемы базы данных. Варианты проектирования физической схемы.

При проектировании физической схемы следует начинать с чисто логической модели — хорошо разобраться в основных бизнес-правилах и задокументировать их. Только так можно создать простую и гибкую модель, которая хорошо проявит себя в работе. Реализация физической схемы базы данных включает в себя шесть компонентов.

¾ Создание файлов базы данных.

¾ Создание таблиц.

¾ Создание первичных и внешних ключей.

¾ Создание столбцов данных.

¾ Создание ограничений, гарантирующих целостность данных.

¾ Создание индексов (в принципе индексы могут быть без труда созданы и изменены уже после реализации физической схемы).

 

Преобразование логической схемы базы данных в физическую может включать несколько этапов.

¾ Преобразование сложного логического проекта в более простые и гибкие структуры таблиц.

¾ Преобразование составных первичных ключей в опирающиеся только на один столбец.

¾ Преобразование бизнес-логики в ограничения и триггеры.

¾ Преобразование логических отношений “многие ко многим” в пары физических отношений “один ко многим”, использующих ассоциативные (или связывающие) таблицы.

Варианты проектирования физической схемы

Каждая команда проектировщиков создает физическую схему, исходя из логической, используя следующие возможные подходы.

¾ Логическая схема базы данных создается, а затем реализуется без оглядки на физическую схему.Такой подход является прямой дорогой к медленной и нерасширяемой схеме базы данных.

¾ Логическая схема базы данных создается при хорошем понимании требований бизнес- логики. Данный подход способен обеспечить создание быстрой и жизнеспособной схемы.Такой подход определяет создание схемы в два этапа, что требует привлечения относительно большого коллектива разработчиков. При этом одна группа программистов собирает бизнес-правила, а вторая занимается их реализацией в физической схеме.

¾ Третья комбинация методологий логического и физического проектирования объединяет весь процесс в один этап. При этом команда проектировщиков сразу создает физическую схему, основываясь на требованиях бизнес-логики. Этот метод хорошо себя проявит, если команда в полной мере понимает вопросы логического и физического моделирования, а также создания сложных запросов.

Ключевой задачей в проектировании физической схемы базы данных является рассмотрение нескольких моделей, каждая из которых удовлетворяет требованиям конечных пользователей и целостности данных. Каждый из проектов должен рассматриваться с точки зрения его простоты, быстродействия, гибкости и легкости обслуживания.

 

 

Корректировка модели данных. Вопросы производительности. Вопросы масштабируемости. Ответственный подход к денормализации.

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

Вопросы производительности

Нормализованная логическая модель базы данных, созданная без оглядки на оптимизацию физической схемы, никогда не даст хорошие результаты, так как при создании логической схемы редко рассматриваются вопросы производительности. На производительность базы данных сильно влияет простота и сложность модели. Каждая новая сложность требует излишнего программирования, объединений и влечет за собой другие дополнительные сложности. Одно из решений проблемы производительности заключается в правильном выборе первичных ключей.

Вопросы масштабируемости

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

¾ Использование последовательного соглашения об именах.

¾ Избежание создания сложных структур данных там, где с задачей могут справиться и более простые структуры.

¾ Использование сценариев, а не Management Studio.

¾ Избежание использования непереносимых расширений, не входящих в стандарт ANSI SQL.

¾ Поддержание целостности данных с помощью ограничений с самого начала разработки.

¾ Изначальная разработка ядра системы.

¾ Документирование не только того, как работает процедура, но и почему она работает именно так.