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

Как мы уже отмечали в Лекции 11, к спецификации языка SQL можно относиться как к спецификации некоторой модели данных, в некоторых аспектах близкой к реляционной модели. Мы стремимся к тому, чтобы порядок лекций, посвященных языку SQL, способствовал правильному пониманию именно этой модели, а не технических тонкостей языка. Предыдущая лекция посвящалась тому, что (т.е. каких типов данные) может храниться в SQL-ориентированной базе данных.

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

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

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

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

Ø Во-первых, используя язык SQL, можно не нарушать предписаний реляционной модели, и тогда к “правильно построенной” SQL-ориентированной базе данных применимы все фундаментальные результаты теории реляционных баз данных, включая принципы проектирования на основе нормализации.

Ø Во-вторых, полностью отвергая родство языка SQL с реляционной моделью данных, мы выступали бы против установившихся исторических традиций. Этот язык возник около 30 лет тому назад во время выполнения в компании IBM проекта по созданию экспериментальной СУБД System R, основной целью которого являлось обоснование практической реализации реляционного подхода к организации баз данных. Так что исторически SQL базировался на реляционной модели данных (возможно, не совсем верно понятой и/или воплощенной).

Ø Наконец, по нашему мнению, в области информационной технологии любой практически используемый инструмент не может быть полностью свободен от компромиссов. Идеологически чистые решения возможны только в научно-экспериментальной работе. Великий и ужасный язык SQL – это порождение ряда компромиссов между теорией, практикой и маркетинговой деятельностью. Этот язык является настолько реляционным, насколько это понадобилось потребителям коммерческих СУБД, прямо или косвенно финансировавшим разработку языка.

В операторе SQL CREATE TABLE специфицируются не только столбцы таблицы, но и ограничения целостности, которым должны удовлетворять данные, хранимые в базовой таблице. Эти ограничения являются частным случаем ограничений базы данных целиком, для определения, изменения и ликвидации имеются специальные операторы. Обсуждению этих средств посвящен второй основной раздел этой лекции.

Дата добавления: 2014-01-03