Некоторые замечания о терминологии

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

А истина заключается в том, что отношение – это не таблица, кортеж – не строка, а атрибут – не столбец. И хотя в неформальном контексте та- кое словоупотребление может показаться приемлемым – я и сам так час- то говорю, – я настаиваю, что приемлемо оно лишь в том случае, когда мы ясно понимаем, что эти дружественные термины – не более чем приближение к истине, они совершенно не ухватывают смысл того, что происходит на самом деле. Скажу по-другому: если вы понимаете истинное положение вещей, то благоразумное употребление дружественных терминов может оказаться здравой идеей, но, чтобы понять и оценить это истинное положение, необходимо освоить более формальную терминологию. Поэтому в этой книге я буду, как правило, пользоваться формальными терминами – по крайней мере тогда, когда говорю о реляционной модели, противопоставляя ее SQL, – и в нужном месте приведу их строгие определения. Напротив, в контексте SQL я буду употреблять присущую ему терминологию.

И еще одно замечание о терминологии: упомянув, что SQL пытается упростить один набор терминов, я должен добавить, что он сделал все возможное для усложнения другого. Я имею в виду использование терминов оператор, функция, процедура, подпрограмма и метод; все они обозначают по существу одно и то же (быть может, с незначительными вариациями). В этой книге я всюду буду употреблять слово оператор.

Раз уж зашла речь об SQL, позвольте напомнить, что (как отмечалось в предисловии) под этим я понимаю исключительно стандартную вер сию языка1, если не считать нескольких мест, где по контексту требуется иное.

Иногда я употребляю терминологию, отличающуюся от стандартной. Например, я пишу табличное выражение (table expression) вместо принятого в стандарте выражение запроса (query expression), по- тому что (а) значением такого выражения является таблица, а не запрос, и (б) запросы – не единственный контекст, в котором такие выражения используются. (На самом деле, в стандарте применяется термин табличное выражение, но в гораздо более узком смысле; конкретно, он обозначает то, что следует за фразой SELECT в выражении SELECT.)

Продолжая предыдущую мысль, должен добавить, что не все табличные выражения допустимы в SQL в любом контексте, где их использование можно было бы предположить. В частности, результат явной операции JOIN, хотя он, безусловно, обозначает таблицу, не может встречаться в качестве «отдельно стоящего» табличного выражения (то есть на самом внешнем уровне вложенности), а также не может выступать в качестве табличного выражения в скобках, кото- рое составляет подзапрос (см. главу 12). Обратите внимание, что подобные замечания применимы ко многим обсуждениям в основ-

ном тексте книги, но повторять их каждый раз было бы скучно, поэтому я этого делать не буду. (Однако все это сведено в БНФ- грамматике в главе 12.)

Я игнорирую те аспекты стандарта, которые можно считать чрезмерно эзотерическими, особенно если они не являются частью того, что

в стандарте называется Core SQL (Базовый SQL), или имеют мало общего с реляционной обработкой как таковой. В качестве приме-

ров упомяну так называемые аналитические или оконные функции (OLAP), динамический SQL, рекурсивные запросы, временные таблицы и детали типов, определенных пользователем.

По причинам, отчасти связанным с типографским набором, я при- меняю для комментариев стиль, отличающийся от стандартного. Точнее, комментарии печатаются курсивом и обрамлены ограничителями «/*» и «*/».

Не забывайте, что все реализации SQL включают средства, не описанные в стандарте. Типичный пример – идентификаторы строк. Моя общая рекомендация относительно таких средств такова: пользуйтесь ради бога, но только если они не нарушают реляционных принципов (в конце концов, эта книга посвящена описанию реляционного подхода к SQL). Например, применение идентификаторов строк, скорее всего, нарушит так называемый принцип взаимозаменяемости (см. главу 9), и если это так, я бы точно не стал их использовать. Но и в этом,

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