Язык реляционных баз данных SQL. Проектирование реляционных баз данных

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

При проектировании базы данных решаются две основные проблемы:

· Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области, и было, по возможности, лучшим (эффективным, удобным и т. д.)? Часто эту проблему называют проблемой логического проектирования баз данных.

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

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

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

Основные свойства нормальных форм такие:

· каждая следующая нормальная форма в некотором смысле лучше предыдущей;

· при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.

Процесс проектирования реляционной базы данных на основе метода нормализации преследует две основные цели:

· избежать избыточности хранения данных;

· устранить аномалии обновления отношений.

Из рассмотрения реляционной модели известно, что двумя фундаментальными языками запросов к реляционным базам данных являются языки реляционной алгебры и реляционного исчисления. При всей своей строгости и теоретической обоснованности, эти языки не стали стандартными языками реляционных СУБД. Юридическим и фактическим стандартом стал язык SQL (Structured Query Language – «язык структурированных запросов»).

SQL представляет собой некоторую комбинацию реляционного исчисления кортежей и реляционной алгебры, и был разработан в середине 70-х годов в компании IBM в рамках проекта экспериментальной реляционной СУБД System R. Деятельность по стандартизации SQL началась практически одновременно с появлением его первых коммерческих реализаций. В 1986 г. был принят стандарт ANSI, а в 1987 г. Этот стандарт был одобрен международной организацией по стандартизации (ISO). Время от времени выпускается пересмотренная версия этого стандарта; наиболее свежее обновление было выпущено в 2008 г.

Формальное название стандарта SQL – ISO/IEC 9075 «Database Language SQL».

Несмотря на наличие международного стандарта, многие производители СУБД вносят изменения в язык SQL, тем самым отступая от стандарта. В результате у разных производителей СУБД в ходу разные диалекты SQL, в общем случае между собой несовместимые. В настоящее время проблема совместимости решается так: описание языка имеет модульную структуру, основная часть стандарта вынесена в раздел «SQL/Foundation», все остальные выведены в отдельные модули, остался только один уровень совместимости – «Core», что означает поддержку этой основной части. Поддержка остальных возможностей оставлена на усмотрение производителей СУБД.

Все операторы, составляющие основу SQL с момента его появления, можно разделить на следующие группы:

· операторы определения данных (Data Definition Language – DDL)

o CREATE создает объект базы данных

o ALTER изменяет объект

o DROP удаляет объект

· операторы манипуляции данными (Data Manipulation Language – DML)

o SELECT считывает данные, удовлетворяющие заданным условиям

o INSERT добавляет новые данные

o UPDATE изменяет существующие данные

o DELETE удаляет данные

· операторы определения доступа к данным (Data Control Language – DCL)

o GRANT предоставляет пользователю (группе) разрешения на определенные операции с объектом

o REVOKE отзывает ранее выданные разрешения

o DENY задает запрет, имеющий приоритет над разрешением

· операторы управления транзакциями (Transaction Control Language – TCL)

o COMMIT применяет транзакцию.

o ROLLBACK откатывает все изменения, сделанные в контексте текущей транзакции.

o SAVEPOINT делит транзакцию на более мелкие участки.

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