Программирование баз данных MS SQL Server (1084479), страница 39
Текст из файла (страница 39)
Однако настоятельно рекомендуется использовать новый формат операторов, предусмотренный стандартом АХИ, которому посвящена основная часть настоящей главы, поскольку он является более удобным для чтения, не допускает возникновения неоднозначностей, характерных для устаревшего синтаксиса, а его поддержка в СУБД БЯ1. Яегчег всегда гарантирована.
В следующих нескольких главах будет показано, как создавать собственные таблицы и связывать их друг с другом. По мере изучения этого материала основные принципы формирования соединений таблиц с использованием согласуемых друг с другом столбцов станут еще более очевидными. 160 Глава 4 Упражнения 4.1. Напишите запрос к базе данных Нотспю1пб, который возвращает один столбец Япрр11етиате и содержит имя поставщика товара СЬа1. 4.2. Напишите запрос с конструкцией Ю01н, чтобы получить список с указанием каждой территории в базе данных нотспю1по, для обслуживания которой не назначен служащий. (Подсказка. Используйте внешнее соединение.) Создание и модификация таблиц Студенты, которые изучают, как применяется код Т-ЯО) для создания баз данных, таблиц, ключей и ограничений, часто задают один и тот же вопрос: "Нельзя ли выполнить все эти действия с помощью инструментального средства с графическим интерфейсом пользователяУ" Ответ на этот вопрос, безусловно, является положительным.
Но за этим вопросом обычно сразу же следует другой; "Так зачем же тратить время на изучение того, что никогда не потребуется в работе?" Ответ является столь же однозначным — на практике время от времени все равно приходится использовать обычный синтаксис. В действительности нет необходимости неизменно разрабатывать код создания и модификации объектов базы данных с нуля, но в большинстве крупных проектов баз данных этот код приходится проверки ь и редактировать, а это означает, что необходимо разбираться в том, как он работает. Настоящая глава посвящена изучению синтаксиса операторов, применяемых для создания пользователем собственных таблиц.
Кроме того, в ней описано, как воспользоваться программой Я~) Мапаяешепг Сопзо)е для упрощения этой работы (это описание будет приведено после изучения способов самостоятельного выполнения всех необходимых для этого задач). Прежде чем перейти к глубокому изучению операторов, фактически используемых для создания таблиц и других объектов, мы должны сделать достаточно большое отступление, чтобы рассмотреть, какие соглашения распространяются на структуру полностью уточненных имен объектов, а также в меньшей степени на права использования объектов.
1б2 Глава 5 Структура имен объектов в СУБД ЗЖ Зегмег Во всех запросах, которые рассматривались до сих пор в настоящей книге, использовались простые средства именования. Перед выполнением любых запросов автор предлагал активизировать требуемую базу данных в программе Япегу Апа!узег, благодаря чему обеспечивалось выполнение запросов применительно к тому объекту, для которого они предназначены. В этих случаях необходимость переключения на другую базу данных была связана с тем, что при использовании имен, не имеющих уточнений, СУБД оЯ) $егуег, осуществляя попытки идентифицировать и найти объекты, указанные в запросах и других операторах, рассматривает только очень ]экую область определения.
Таким образом, в рассматриваемых до сих пор примерах было предусмотрено применение только имен таблиц, без какой-либо дополнительной информации, но фактически для именования любых таблиц СУБД ба Яегуег (а также, в этом контексте, любых других объектов ЯЯ[. Яегуег) предусмотрено соглашение, допускающее использование четырех уровней именования. Полностью уточненное имя имеет такую структуру: [Бегчегиаве. [ОяпаЬаяеяаве. [Бспевававе. ] ] ] ОЬ) еспваве При выполнении любой операции над объектом необходимо указать имя этого объекта, но все остальные части уточненного имени, находящиеся слева от имени объекта, Оь) есс][аве, являются необязательными. И действительно, чаще всего без дополнительных уточнителей вполне можно обойтись, поэтому они не применяются.
Тем не менее, прежде чем приступить к созданию объектов, следует полностью разобраться в том, что означает каждая часть уточненного имени. Ниже компоненты структуры уточненного имени рассматриваются справа налево. Имя схемы (или обозначение принадлежности) Схемой (ясйеша) называется часть базы данных, принадлежащая определенному пользователю. В большинстве создававшихся ранее баз данных принцип распределения объектов по схемам не использовался, но складывается впечатление, что необходимость реализации этого принципа в дальнейшем будет становиться все более и более насущной. Если в базе данных используются схемы, то для обеспечения доступа к объектам требуется указывать, в какой схеме находятся эти объекты.
Вполне допустимо, чтобы в базе данных имелись два объекта с одинаковыми именами, находящиеся в разных схемах. Если пользователь желает получить доступ к объекту, который не находится в схеме этого пользователя, применяемой по умолчанию (которая определяется во время регистрации пользователя), то он должен конкретно указывать имя схемы, Бсйева]лаве, в которой находится объект. Например, рассмотрим вариант применения схем в базе данных йс[уепспгеногЬБ (кстати, это — один из наихудших вариантов организации схем, которые когда-либо встречались автору) и составим запрос на получение списка сотрудников с указанием городов, в которых они проживают: БЕЬЕСТ е.ввр1оуее1О, с.Р1гяпваве, с.ьаяпнавя, Сзпу РЕОМ Нивапвеяопгсея.Евр1оуее АБ е д01М Регяоп.Соппасп с ОМ е.соппасп1О = с.соппясп1В Создание и модификация таблиц 163 301Н Нпвапнезоигсез.Евр1оуееаеегезз АЯ еа ОИ е.Евр1оуее1О = еа.Евр1оуее1О 101И Регзоп.адегеэз Аз а ОИ еа.АННгезз1О = а.хеегезз1О В данном примере используются четыре таблицы, распределенные по двум схемам.
Если бы оказалось так, что одна из двух рассматриваемых схем (Нпвапреэоигсеэ или регэоп) является схемой, применяемой по умолчанию, то можно было бы не задавать имя этой схемы, составляя в запросе имена таблиц, находящихся в схеме. Но в данном случае указаны имена всех схем, поскольку это позволяет избежать любых неприятных сюрпризов. Настоящий пример иллюстрирует еще одну ситуацию, в которой автор неизменно настаивает, что нужно придерживаться единообразия.
Если в процессе работы приходится использовать средства базы данных, предусматривающие распределение объектов по схемам, то автор настоятельно рекомендует придерживаться во всех запросах соглашения об именовании, в соответствии с которым каждое имя должно состоять из двух частей (имя схемы и имя таблицы).
Дело в том, что слишком легко могут возникнуть такие предпосылки нарушения в работе, при которых изменится схема, применяемая пользователем по умолчанию, или будет переопределен какой-то другой псевдоним, в результате чего предположения, касающиеся выбора компонентов имен, заданных по умолчанию, станут недействительными. Если до сих пор во всех ваших проектах баз данных не использовался принцип распределения объектов по разным схемам, то имеет смысл оставить все эти проекты в неизменном виде (что способствует также значительному повышению удобства чтения кода), но если в дальнейшем вы перейдете к использованию схем, то придется столкнуться с дополнительными сложностями. Некоторые вспомогательные сведения о схемах В стандарте АХИ языка БЯЕ понятие, связанное со структуризацией баз данных, получившее название схемы, было сформулировано уже довольно давно. Следует отметить, что в СУБД ЯО1.
Яегуег аналогичная концепция была реализована с самого начала, но лля ее именования использовались другие термины (а также, безусловно, даже если бы можно было применить для обозначения этого понятия то же название, оно имело бы немного другое назначение). Поэтому, в частности, в предыдущих версиях БО1. Яегуег то, что принято называть "схемой" в ЯО1. Бегуег 2005 и других базах данных, таких как Огас!е, обычно именовалось "владельцем". Подход, предусматривающий применение способа структуризации баз данных с помощью схем, выдержал проверку временем.
Безусловно, сама реализация этого способа все еще остается достаточно сложной, но компания М)сгозо11 ввела несколько новых усовершенствований в программное обеспечение ЯО1. Бегуег 2005, благодаря чему решение проблем, связанных с использованием схем, значительно упростилось. Но если в процессе работы необходимо обеспечивать обратную совместимость с предыдущими версиями БО(.
Бегуег, то следует либо полностью избегать применения новых средств, либо учитывать все нюансы, связанные с использованием устаревших, а это означает, что стремление реализовать в новых проектах понятие "владельца" (предусмотренное в предыдущих версиях) становится источником существенных затруднений. Разумеется, определенная часть разработчиков всегда с трудом расстается с теми средствами, которые должны быть подвергнуты пересмотру. В качестве примера 164 1)гана 5 можно привести использование понятия "владельца" в версиях, предшествующих БЯ1.
Яеггег 2005, но автор, беэусловно, не относится к такой категории разработчиков. Важной отличительной особенностью версии БЯЕ Яегчег 2005, о которой всегда следует помнить, является то, что в ней изменилась структура имен в связи с отказом от понятия "владельца", поэтому та часть базы данных, в которой находятся объекты, принадлежащие определенному пользователю, теперь обозначается термином "схема", более совместимым со стандартом АХАТЬ Такое изменение подхода следует учитывать не только потому, что компания М!сгогой стала на путь перехода от использования понятия "владельца" к применению понятия "схемы", но и в связи с тем, что работа в этом направлении продолжается, а это означает, что в будущих проектах отказ от использования схем станет уже невозможным. В версии 5(1).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
