Физическая реализация. Часть 2

Подключение к серверу и интерфейс среды

После подключения к серверу баз данных в окне указывается имя сервера и выбирается пользователь. Это может быть учётная запись операционной системы (Windows) или внутренняя учётная запись SQL Server. Основные компоненты среды включают список баз данных, а также папку Security. Она отвечает за список пользователей и разграничение прав. Вкладка Logins отображает перечень пользователей, имеющих право подключения к серверу: сюда входят и учётные записи Windows, и внутренние логины SQL Server.

Внутренние технические пользователи, обеспечивающие работу сетевых служб, не представляют интереса для разработчика. Ключевым является SA (System Administrator) — встроенная учётная запись администратора сервера, отсутствующая на уровне операционной системы. Первоочередная задача — задать для SA пароль и включить его (состояние Grant и Enabled), так как по умолчанию он отключен (Disabled). Внутренние пользователи необходимы, когда приложение (например, веб-приложение) подключается к базе данных: использование учётных записей Windows, под которыми работают администраторы сервера, нарушает нормы безопасности. Для каждого приложения заводят отдельный логин и пароль.

Роли и разрешения

Пользователь SA обладает ролью sysadmin уровня сервера, автоматически включается в роль public, дающую лишь базовую возможность подключения. Все остальные действия требуют дополнительных разрешений. Список ролей — это предустановленный перечень, который можно расширять. Роль — это набор разрешений (permissions), назначаемый пользователям. Это избавляет от необходимости назначать права каждому пользователю по отдельности: создаётся роль с нужной комбинацией разрешений, затем пользователям присваиваются соответствующие роли. На уровне базы данных также можно создавать собственных пользователей и роли.

Вкладка User Mapping показывает список всех баз данных и позволяет назначить пользователю отдельные роли в каждой из них. Поскольку SA — администратор, он является владельцем большинства баз и имеет полный доступ, даже если явно указана только роль public. Иерархия ролей обеспечивает приоритет: роль уровня сервера перекрывает настройки уровня базы данных. В реальных проектах администратор заранее создаёт роли и пользователей согласно техническому заданию; конечный пользователь часто даже не знает учётные данные — они «вшиты» в клиентское приложение (ERP, CRM), а за ним закреплена роль в базе данных.

Любое действие в графическом интерфейсе Management Studio приводит к автоматической генерации скрипта T-SQL, исполняемого на сервере. Вкладка Script во многих окнах позволяет увидеть этот код и при необходимости использовать его для повторения операций.

Создание базы данных

При создании новой базы данных (через контекстное меню папки Databases) задаются следующие параметры:
• Имя базы данных (например, Cinema).
• Владелец: по умолчанию им становится пользователь, создающий базу. При необходимости можно сменить на внутреннего пользователя.
• Файлы: база состоит минимум из двух файлов. Первый — файл данных (строки таблиц), второй — файл журнала транзакций (лог, log file), хранящий историю всех манипуляций (кто, когда, какие изменения внёс). Имена и пути размещения настраиваются; по умолчанию используется путь, заданный в настройках сервера.
• Размер и авторасширение: указывается начальный размер каждого файла и шаг прироста. Можно задать максимальный размер, чтобы избежать переполнения диска. При достижении лимита вставка новых строк станет невозможной — потребуется архивирование и очистка устаревших данных. В промышленных системах резервное копирование (бэкап) и репликация (создание клонов с заданной периодичностью) автоматизируются.

Дополнительные настройки базы данных

Вкладка Options содержит:
• Кодировку (collation). Определяет правила сортировки и набор символов. Если база ограничена английским языком, достаточно латинской кодировки. Для хранения специфических символов (например, знак копирайта) требуется Unicode. По умолчанию настройки наследуются от сервера, но для конкретной базы их можно изменить.
• Модель восстановления (Recovery model). Варианты: Full (полное протоколирование каждого действия), Simple (фиксируется только итоговый результат). Выбор Simple уменьшает размер журнала транзакций, что удобно для учебных и тестовых сред.
• Уровень совместимости (Compatibility level). Позволяет перенести базу на более раннюю версию SQL Server. Выбирается требуемая версия; по умолчанию соответствует текущей.

Вкладка Filegroups в данном контексте несущественна.

Все выполненные настройки преобразуются в T-SQL скрипт, доступный по кнопке Script. После нажатия OK база появляется в списке.

Серверные настройки безопасности и памяти

В свойствах сервера (контекстное меню корневого узла) можно:
• В разделе Memory управлять объёмом памяти, выделяемой SQL Server.
• В разделе Security выбрать режим аутентификации: только Windows Authentication либо SQL Server and Windows Authentication (смешанный режим). Переключение режима или изменение других свойств требует перезапуска службы SQL Server. Это можно сделать через оснастку «Службы» в Windows или внутренний SQL Server Configuration Manager.

Проектирование таблиц и типы данных

В папке Tables создаётся новая таблица. Первый столбец — суррогатный первичный ключ типа int (целое число). Числовые ключи значительно эффективнее текстовых при хранении, сортировке, фильтрации и поиске. Тип int назначается первичным ключом (значок ключика), что автоматически снимает флаг Allow Nulls — значение должно быть обязательно и уникально для каждой строки.

Текстовые типы данных:
• char(n) — строка фиксированной длины n. Если реальная строка короче, остаток дополняется пробелами. Сам тип «дешевле» по накладным расходам, но при переменной длине данных память расходуется неэффективно.
• varchar(n | max) — строка переменной длины, хранится ровно столько символов, сколько введено. Экономит память при сильной вариации длин. Параметр max позволяет хранить очень большие строки (до 2 ГБ).
• nchar(n) и nvarchar(n | max) — те же типы, но для символов в кодировке Unicode. На каждый символ выделяется вдвое больше памяти, что даёт возможность сохранять расширенный набор символов (например, знак копирайта © как один символ). Префикс N важен, если поле может содержать специфические символы.

Правило выбора: если длина поля принципиально не варьируется (например, ИНН), используют char; если варьируется (названия городов, адреса), — varchar. Если ожидаются нестандартные символы, добавляют N.

Создание таблиц базы данных «Кинотеатр»

1. Таблица City — города.
Поля: ID (int, первичный ключ), CityName (varchar(30), не допускает NULL). Идентификатор города — суррогатный ключ.
2. Таблица Cinema — кинотеатры.
Поля: ID (int, первичный ключ), ID_City (int, внешний ключ к City, не NULL), Address (varchar(50), не NULL), CinemaName (varchar(20), допускает NULL). Внешний ключ ссылается на ID города.
3. Таблица Hall — залы кинотеатров.
Поля: ID (int, первичный ключ), ID_Cinema (int, внешний ключ к Cinema, не NULL), HallName (varchar(20), не NULL). Название зала (номер или имя) обязательно; идентификатор зала уникален глобально, а не только в пределах кинотеатра.
4. Таблица Format — справочник форматов показа.
Поля: ID (int, первичный ключ), FormatName (varchar(20), не NULL), Description (nvarchar(50), допускает NULL). Описание может содержать спецсимволы, поэтому выбран nvarchar.

Реализация связи «многие ко многим»

Зал может поддерживать несколько форматов, и один формат встречается во многих залах — образуется связь «многие ко многим». На физическом уровне она реализуется через ассоциативную таблицу HallFormat.
Поля: ID_Hall (int), ID_Format (int). Вместе они образуют составной первичный ключ (выделяются оба поля и назначаются первичным ключом). Оба поля — внешние ключи, ссылающиеся на Hall и Format соответственно, и не допускают NULL. Дополнительные собственные поля отсутствуют, поэтому эта таблица является именующей — частным случаем ассоциативной таблицы.

Диаграмма базы данных и внешние ключи

Для наглядного связывания таблиц используется диаграмма (Database Diagrams). На пустой холст добавляются все созданные таблицы. Чтобы физически создать внешний ключ, нужно перетащить первичный ключ родительской таблицы на соответствующее поле дочерней. Например, ID из City перетаскивается на ID_City в Cinema. В появившемся окне свойств связи можно настроить поведение при удалении родительской записи: запретить удаление или настроить каскадное удаление (автоматическое удаление всех зависимых строк из дочерних таблиц перед удалением родительской). В реальной практике удаление данных редко применяется из-за необходимости сохранять историю.

На диаграмме связи отображаются графически: первичные ключи помечаются значком ключа, внешние — символом бесконечности для отношения «один ко многим». Сохранение диаграммы подтверждает все созданные связи, после чего получается полноценная физическая модель базы данных.

Важно: в настройках Management Studio (Tools → Options → Designers) необходимо снять флажок «Prevent saving changes that require table re-creation», чтобы разрешить изменения структуры таблиц, требующие их пересоздания. Без этого графические операции, ведущие к неявному удалению и созданию таблиц, будут заблокированы.

Краткие итоги

Построение базы данных начинается не с таблиц, а с разграничения доступа. Административный контур сервера чётко разделяет субъекты: учётные записи операционной системы и изолированные логины SQL Server. Первые уместны при личной разработке, вторые — единственно приемлемый вариант для промышленного приложения, где клиентская программа не должна оперировать привилегиями системного администратора сервера. Отсюда вырастает ролевая модель: вместо прямого наделения правами каждого пользователя вводятся поименованные наборы разрешений. Иерархия ролей — от уровня сервера к уровню конкретной базы — создаёт гибкий механизм, при котором прикладной пользователь даже не знает технических деталей, а только получает доступ через «вшитые» в приложение креденции.

Переход к физическому проектированию базы демонстрирует, как абстрактная логическая схема обретает плоскую табличную реализацию. Отказ от естественных составных ключей в пользу целочисленных суррогатных идентификаторов не только упрощает соединения, но и кардинально ускоряет поиск и сортировку. Выбор между семействами char/varchar и их юникодными расширениями диктуется не только длиной данных, но и реальной потребностью хранить расширенные символы — решение, которое принимается на основе анализа предметной области (например, поле комментария веб-приложения против поля фиксированного формата ИНН). Ограничение Allow Nulls фиксирует бизнес-правило об обязательности заполнения атрибута прямо в схеме, предотвращая появление неполных записей.

На уровне связей фундаментальным приёмом становится разрешение отношения «многие ко многим» через промежуточную таблицу. В рассматриваемом примере зал может иметь несколько форматов, а формат — использоваться во многих залах; введение именующей таблицы HallFormat с составным первичным ключом превращает нереализуемое напрямую отношение в два стандартных «один ко многим». Диаграмма базы данных выступает не просто иллюстрацией, а инструментом верификации: перетаскивание ключа с родительской таблицы на дочернюю фиксирует ограничение внешнего ключа, а параметры каскадного удаления заставляют проектировщика сразу продумывать стратегию поддержания ссылочной целостности.

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