SQL простыми словами: основы и применение — Boodet.online

SQL простыми словами: основы и применение — Boodet.online Расшифровка

Sql, хранилища данных и интеллектуальные ресурсы предприятия

Несколько лет усилий по внедрению технологии SQL в сферу разработки OLTP-приложений сделали свое дело, и реляционные базы данных стали цениться не только за удобство выполнения запросов и поддержку принятия решений. Тес­ты производительности и отчаянное соперничество между ведущими СУБД пере­местились в область простых транзакций, таких как добавление новых заказов в базу данных или определение баланса счетов клиента.

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

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

В противопо­ложность этому запросы, связанные с принятием решений (например, «Какова средняя стоимость заказов для данного региона?» или «Насколько увеличился сбыт продукции по сравнению с аналогичным периодом прошлого года?»), могут требовать сканирования огромных таблиц и выполняться минутами или даже ча­сами.

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

Необходимость в полноценном использовании информационного потенциала предприятия, т.е. накопленных им данных, а также практические проблемы, связан­ные с производительностью OLTP-систем, породили новое технологическое реше­ние, получившее название «хранилище данных» (data warehouses).

Идею хранили­ща данных иллюстрирует схема на рис. 6. Бизнес-данные извлекаются из OLTP- систем предприятия, форматируются, проверяются и помещаются в отдельную базу данных, предназначенную исключительно для делового анализа («хранилище»). Из­влечение и форматирование данных можно выполнять на периодической основе в пакетном режиме во время наименьшей загрузки системы.

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

Рис. 6.Концепция хранилищ данных

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

Не тратили времени зря и производители СУБД, сконцен­трировавшие свое внимание на типичных запросах делового анализа. Эти запро­сы, как правило, бывают большими и сложными, как, например, анализ десятков или сотен миллионов отдельных операций оплаты товара для выявления наиболее распространенных схем оплаты, и часто связаны с обработкой хронологических данных — скажем, анализ ежемесячного изменения объема продаж или доли ком­пании в своем сегменте рынка.

Для удовлетворения специфических потребностей приложений, работающих с хранилищами данных и часто называемых приложениями для оперативной аналитической обработки данных (Online Analytical Processing, OLAP), стали по­являться специализированные СУБД. Их производительность оптимизирована для выполнения сложных запросов, связанных только с чтением данных.

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

Среди специализированных СУБД есть некоторое количество таких, ко­торые не используют язык SQL, но большинство использует именно его, благо­даря чему получил распространение еще один сопутствующий термин — реля­ционная оперативная аналитическая обработка данных (Relational Online Analytical Processing, ROLAP).

Эволюция рынка хранилищ данных привела к тому, что новым важным сег­ментом рынка стали инструменты для работы с хранилищами, часто именуемые интеллектуальными ресурсами (businessintelligence). Три ведущие компании в этой области достигли немалого успеха на рынке до того, как были куплены промышленными гигантами.

Компания Business Objects была приобретена SAP, ведущим производителем приложений уровня предприятия. Компания Hyperion досталась Oracle, a Cognos — IBM. Как и во многих других сегментах рынка, достоинства SQL в качестве стандарта сделали его важным фактором развития и обеспечили закрепление на рынке SQL-хранилищ данных и анали­тического инструментария.

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

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

В этой статье мы рассмотрим основные понятия sql. Расскажем его предысторию (и развеем попутно несколько мифов). Вы познакомитесь с реляционной моделью и сможете приобрести первые навыки работы с sql, что поможет в дальнейшем освоении языка.

Трудно ли изучить sql? Это зависит от того, насколько глубоко вы собираетесь вникать в суть. Для того чтобы стать профессионалом, придется изучить очень многое. Язык sql появился в 1974 г. как предмет небольшой исследовательской работы, состоявшей из 23 страниц, и с тех пор прошел долгий путь развития. Текст действующего ныне стандарта — официального документа «the international standard database language sql» (обычно называемого sql-92) — содержит свыше шести сотен страниц, однако в нем ничего не говорится о конкретных особенностях версий sol, реализованных в СУБД фирм microsoft, oracle, sybase и др. Язык настолько развит и разнообразен, что лишь простое перечисление его возможностей потребует нескольких журнальных статей, а если собрать все, что написано на тему sol, то получится многотомная библиотека.

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

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

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

Наиболее существенным свойством sql является возможность доступа к реляционным БД. Многие даже считают, что выражения «БД, обрабатываемая средствами sql» и «реляционная БД» — синонимы. Однако скоро вы убедитесь, что между ними имеется разница. В стандарте sql-92 даже нет термина отношение (relation).

Если не вдаваться в подробности, то реляционная СУБД — это система, основанная на реляционной модели управления данными.

Понятие реляционной модели было впервые предложено в работе д-ра Е. Ф. Кодда, опубликованной в 1970 г. В ней был описан математический аппарат для структуризации данных и управления ими, а также предложена абстрактная модель для представления любой реальной информации. До этого при использовании БД требовалось учитывать конкретные особенности хранения в ней информации. Если внутренняя структура БД изменялась (например, с целью повышения быстродействия), приходилось перерабатывать прикладные программы, даже если на логическом уровне никаких изменений не происходило. Реляционная модель позволила отделить частные особенности хранения данных от уровня прикладной программы. В самом деле, модель никак не описывает способы хранения информации и доступа к ней. Учитывается лишь то, как эта информация воспринимается пользователем. Благодаря появлению реляционной модели качественно изменился подход к управлению данными: из искусства оно превратилось в науку, что привело к революционному развитию отрасли.

Другие сокращения:  Что значит пэс - Значения слов

Согласно реляционной модели, отношение (relation) — это некоторая таблица с данными. Отношение может иметь один или несколько атрибутов (признаков), соответствующих столбцам этой таблицы, и некоторое множество (возможно, пустое) данных, представляющих собой наборы этих атрибутов (их называют n-арными кортежами, или записями) и соответствующих строкам таблицы.

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

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

Обратите внимание: атрибут обязательно должен иметь одно из допустимых значений. Задание сразу нескольких значений запрещено. Таким образом, помимо требования принадлежности значений атрибута некоторому домену, должно соблюдаться условие его атомарности. Это означает, что для этих значений недопустима декомпозиция, т. е. нельзя разбить их на более мелкие части, не потеряв основного смысла. Например, если бы значение атрибута одновременно содержало Понедельник и Вторник, то можно было бы выделить две части, сохранив первоначальный смысл — ДеньНедели; следовательно, это значение атрибута не является атомарным. Однако если попробовать разбить значение «Понедельник» на части, то получится набор из отдельных букв — от «П» до «К»; исходный смысл утерян, поэтому значение «Понедельник» является атомарным.

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

В своей исходной работе д-р Кодд определил набор из восьми операторов, получивший название реляционной алгебры. Четыре оператора — объединение, логическое умножение, разность и Декартово произведение — были перенесены из традиционной теории множеств; остальные операторы были созданы специально для обработки отношений. В последующих работах д-ра Кодда, Криса Дейта и других исследователей были предложены дополнительные операторы. Далее в этой статье будут рассмотрены три реляционных оператора — продукция (project), ограничения (select, или restrict) и слияние (join).

Теперь, когда вы познакомились с реляционной моделью, давайте забудем о ней. Конечно, не навсегда, а лишь для того, чтобы объяснить следующее: хотя именно предложенная д-ром Коддом реляционная модель была использована при разработке sql, между ними нет полного или буквального соответствия (это одна из причин, почему в стандарте sql-92 отсутствует термин отношение). Например, понятия таблица sql и отношение не являются равнозначными, потому что в таблицах может быть сразу несколько одинаковых строк, тогда как в отношениях появление идентичных кортежей не разрешено. К тому же в sql не предусмотрено использование реляционных доменов, хотя в некоторой степени их роль играют типы данных (некоторые влиятельные сторонники реляционной модели предпринимают сейчас попытку добиться включения в будущий стандарт sql реляционных доменов).

К сожалению, несоответствие между sql и реляционной моделью породило множество недоразумений и споров за прошедшие годы. Но так как основная тема статьи — изучение sql, а не реляционной модели, эти проблемы здесь не рассматриваются. Просто следует запомнить, что между терминами, применяемыми в sql и в реляционной модели, имеются различия. Далее в статье будут использоваться только термины, принятые в sql. Вместо отношений, атрибутов и кортежей будем применять их sql-аналоги: таблицы, столбцы и строки.

Возможно, вам уже знакомы такие термины, как статический и динамический sql. sql-запрос является статическим, если он компилируется и оптимизируется на стадии, предшествующей выполнению программы. Мы уже упоминали одну из форм статического sql, когда говорили о встраивании sql-команд в программы на Си или Коболе (для таких выражений существует еще другое название — встроенный sql). Как вы, наверное, догадываетесь, динамический sql-запрос компилируется и оптимизируется в ходе исполнения программы. Как правило, обычные пользователи применяют именно динамический sql, позволяющий создавать запросы в соответствии с сиюминутными нуждами. Один из вариантов изпользования динамических sql-запросов — их интерактивный или непосредственный вызов (существует даже специальный термин — directsql), когда отправляемые на обработку запросы вводятся в интерактивном режиме с терминала. Между статическим и динамическим sql имеются определенные различия в синтаксисе применяемых конструкций и особенностях исполнения, однако эти вопросы выходят за рамки статьи. Отметим лишь, что для ясности понимания примеры даются в форме direct sql-запросов, поскольку это позволяет научиться использовать sql не только программистам, но и большинству конечных пользователей.

Теперь вы готовы к написанию своих первых sql-запросов. Если у вас имеется доступ к БД через sql и вы захотите воспользоваться нашими примерами на практике, то учтите следующее: вы должны входить в систему как пользователь с неограниченными полномочиями и вам потребуются программные средства интерактивной обработки sql-запросов (если речь идет о сетевой БД, следует переговорить с администратором БД о предоставлении вам соответствующих прав). Если доступа к БД через sql нет — не огорчайтесь: все примеры очень простые и в них можно разобраться «всухую», без выхода на машину.

Для того чтобы выполнить какие-либо действия в sql, следует выполнить выражение на языке sql. Встречается несколько типов выражений, однако среди них можно выделить три основные группы: ddl-команды (data definition language — язык описания данных), dml-команды (data manipulation language — язык манипуляций с данными) и средства контроля за данными. Таким образом, в sql в каком-то смысле объединены три различных языка.

Начнем с одной из основных ddl-команд — create table (Создать таблицу). В sql бывают таблицы нескольких типов, основными являются два типа: базовые (base) и выборочные (views). Базовыми являются таблицы, относящиеся к реально существующим данным; выборочные — это «виртуальные» таблицы, которые создаются на основе информации, получаемой из базовых таблиц; но для пользователей формы выглядят как обычные таблицы. Команда create table предназначена для создания базовых таблиц.

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

create и table — это ключевые слова sql; ИмяТаблицы, Столбец и ТипДанных — это формальные параметры, вместо которых пользователь каждый раз вводит фактические значения. Параметры Столбец и ТипДанных заключены в круглые скобки. В sql круглые скобки обычно используются для группировки отдельных элементов. В данном случае они позволяют объединить определения для столбца. Стоящий в конце знак «точка с запятой» является разделителем команд. Он должен завершать любое выражение на языке sql.

Рассмотрим пример. Пусть нужно создать таблицу для хранения данных обо всех встречах (appointments). Для этого в sql следует ввести команду:

После выполнения этой команды будет создана таблица с именем appointments, где имеется один столбец appointment_date, в котором могут записываться данные типа date. Поскольку на текущий момент данные еще не вводились, количество строк в таблице равно нулю (с помощью команды create table только дается определение таблицы; реальные значения вводятся командой insert, которая рассматривается далее).

Параметры appointments и appointment_date называются идентификаторами, поскольку они задают имена для конкретных объектов БД, в данном случае — имена для таблицы и столбца соответственно. В sql встречаются идентификаторы двух типов: обычные (regular) и выделенные (delimited). Выделенные идентификаторы заключаются в двойные кавычки, и в них учитывается регистр используемых символов. Обычные идентификаторы не выделяются никакими ограниченными символами, в их написании регистр не учитывается. В этой статье применяются только обычные идентификаторы.

Символы, используемые для построения идентификаторов, должны удовлетворять определенным правилам. В обычных идентификаторах могут использоваться только буквы (не обязательно латинские, но и других алфавитов), цифры и символ подчеркивания. Идентификатор не должен содержать знаков пунктуации, пробелов или специальных символов (#, @, % или !); кроме того, он не может начинаться с цифры или знака подчеркивания. Для идентификаторов можно использовать отдельные ключевые слова sql, но делать это не рекомендуется. Идентификатор предназначен для обозначения некоторого объекта, поэтому у него должно быть уникальное (в рамках определенного контекста) имя: нельзя создать таблицу с именем, которое уже встречается в БД; в одной таблице нельзя иметь столбцы с одинаковыми именами. Кстати, имейте в виду, что appointments и appointments — это одинаковые имена для sql. Одним лишь изменением регистра букв создать новый идентификатор нельзя.

Другие сокращения:  Mchc в анализе крови

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

Квадратные скобки использованы для обозначения необязательных элементов, фигурные содержат элементы, которые могут представлять собой перечень однопутных конструкций (при вводе реальной sql-команды ни те ни другие скобки не ставятся). Такой синтаксис позволяет задать любое число столбцов. Обратите внимание, что перед вторым элементом стоит запятая. Если в списке имеется несколько параметров, то они отделяются друг от друга запятыми.

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

Данная команда создает таблицу appointments2 (новая таблица должна иметь иное имя, так как таблица appointments уже присутствует в БД). Как и в первой таблице, в ней имеется столбец appointment_date для записи даты встреч; кроме того, появился столбец appointment_time для записи времени этих встреч. Параметр description (описание) является текстовой строкой, где может содержаться до 256 символов. Для этого параметра указан тип varchar (сокращение от character varying), поскольку заранее не известно, сколько места потребуется для записи, но ясно, что описание займет не более 256 символов. При описании параметро в типа символьная строка (и некоторых других типов) указывается длина параметра. Ее значение задается в круглых скобках справа от названия типа.

Возможно, вы обратили внимание, что в двух рассмотренных примерах запись команды оформлена по-разному. Если в первом случае команда полностью размещена в одной строке, то во втором после первой открытой круглой скобки запись продолжена с новой строки, и определение каждого следующего столбца начинается с новой строки. В sql нет специальных требований к оформлению записи. Разбиение записи на строки делает ее чтение удобнее. Язык sql позволяет при написании команд не только разбивать команду по строкам, но и вставлять отступы в начале строк и пробелы между элементами записи.

Теперь, когда вы знаете основные правила, давайте рассмотрим более сложный пример создания таблицы с несколькими столбцами. В начале статьи была показана таблица employees (Сотрудники). В ней содержатся следующие столбцы: фамилия, имя, дата приема на работу, подразделение, категория и зарплата за год. Для определения этой таблицы используется следующая команда sql:

В команде встречаются несколько новых элементов. Прежде всего, это выражение not null, стоящее в конце определения столбцов last_name и first_name. С помощью подобных конструкций задаются требования, подлежащие обязательному соблюдению. В данном случае указано, что поля last_name и first_name должны обязательно заполняться при вводе; оставлять эти столбцы пустыми нельзя (это вполне логично: как можно идентифицировать сотрудника, не зная его имени?).

Кроме того, в примере присутствуют три новых типа данных: character, smallint и decimal. До сих пор мы почти не говорили о типах. Хотя в sql нет реляционных доменов, однако имеется набор основных типов данных. Эта информация используется при выделении памяти и сравнении величин; в определенной степени сужает список возможных значений при вводе, однако контроль типов в sql менее строгий, чем в других языках.

Все имеющиеся в sql типы данных можно разбить на шесть групп: символьные строки, точные числовые значения, приближенные числовые значения, битовые строки, датовремя и интервалы. Мы перечислили все разновидности, однако в этой статье подробно будут рассматриваться лишь отдельные из них (битовые строки, например, не представляют особого интереса для обычных пользователей).

Кстати, если вы подумали, что датовремя — это опечатка, то ошиблись. К данной группе (datetime) относится большинство используемых в sql типов данных, связанных со временем (такие параметры, как временные интервалы, выделены в отдельную группу). В предыдущем примере уже встречались два типа данных из группы датовремя — date и time.

Следующий тип данных, с которым вы уже знакомы, — character varying (или просто varchar); он относится к группе символьных строк. Если varchar служит для хранения строк переменной длины, то встретившийся в третьем примере тип char предназначен для записи строк, имеющих фиксированное число символов. Например, в столбце last_name будут записываться строки из 13 символов вне зависимости от реально вводимых фамилий, будь то poe или penworth-chickering (в случае с poe оставшиеся 10 символов заполнятся пробелами).

С точки зрения пользователя, varchar и char имеют одинаковый смысл. Зачем нужно было вводить два типа? Дело в том, что на практике обычно приходится искать компромисс между быстродействием и экономией пространства на диске. Как правило, применение строк с фиксированной длиной дает некоторый выигрыш в скорости доступа, однако при слишком большой длине строк пространство на диске расходуется неэкономно. Если в appointments2 для каждой строки комментария резервировать по 256 символов, то это может оказаться нерационально; чаще всего строки будут значительно короче. С другой стороны, фамилии также имеют разную длину, но для них, как правило, требуется около 13 символов; в этом случае потери будут минимальными. Существует хорошее правило: если известно, что длина строки меняется незначительно либо она сравнительно невелика, то используйте char; в остальных случаях — varchar.

Следующие два новых типа данных — smallint и decimal — относятся к группе точных числовых значений. smallint — это сокращенное название от small integer (малое целое). В sql также предусмотрен тип данных integer. Наличие двух схожих типов и в этом случае объясняется соображением экономии пространства. В нашем примере значения параметра grade_level могут быть представлены с помощью двузначного числа, поэтому использован тип smallint; однако на практике не всегда известно, какие максимальные значения могут быть у параметров. Если такой информации нет, то применяйте integer. Реальный объем, выделяемый для хранения параметров типа smallint и integer, и соответствующий диапазон значений для этих параметров индивидуальны для каждой платформы.

Тип данных decimal, обычно используемый для учета финансовых показателей, позволяет задать шаблон с требуемым числом десятичных знаков. Поскольку этот тип служит для точной числовой записи, он гарантирует точность при выполнении математических операций над десятичными данными. Если для десятичных значений использовать типы данных из группы приближенной числовой записи, например float (floating point number — число с плавающей точкой), это приведет к погрешностям округления, поэтому для финансовых расчетов этот вариант не подходит. Для определения параметров типа decimal используется следующая форма записи:

где p — это число десятичных знаков, d — количество разрядов после запятой. Вместо p следует записывать общее число значащих цифр в используемых значениях, а вместо d — количество цифр после запятой.

Во врезке «Создание таблицы» показан полный вариант обобщенной записи команды create table. В нем присутствуют новые элементы и показан формат для всех рассмотренных типов данных (В принципе встречаются и другие типы данных, но пока мы их не рассматриваем).

На первых порах может показаться, что синтаксис sql-команд слишком сложен. Но вы легко в нем разберетесь, если внимательно изучили приведенные выше примеры. На схеме появился дополнительный элемент — вертикальная черта; он служит для разграничения альтернативных конструкций. Другими словами, при определении каждого столбца нужно выбрать подходящий тип данных (как вы помните, в квадратные скобки заключаются необязательные параметры, а в фигурные скобки — конструкции, которые могут повторяться многократно; в реальных sql-командах эти специальные символы не пишутся). В первой части схемы приведены полные названия для типов данных, во второй — их сокращенные названия; на практике можно использовать любые из них.

Первая часть статьи завершена. Вторая будет посвящена изучению dml-команд insert, select, update и delete. Также будут рассмотрены условия выборки данных, операторы сравнения и логические операторы, использование null-значений и троичная логика.

Создание таблицы. Синтаксис команды create table: в квадратных скобках указаны необязательные параметры, в фигурных — повторяющиеся конструкции.

В начале 1970-х гг. в ibm приступили к практическому воплощению модели реляционных БД, предложенной д-ром Коддом. Дональд Чамберлин и группа других сотрудников подразделения перспективных исследований создали прототип языка, получивший название structured english query language (язык структурированных англоязычных запросов), или просто sequel. В дальнейшем он был расширен и подвергнут доработке. Новый вариант, предложенный ibm, получил название sequel/2. Его использовали как программный интерфейс (api) для проектирования первой реляционной системы БД фирмы ibm — system/r. Из соображений, связанных с правовыми нюансами, в ibm решили изменить название: вместо sequel/2 использовать sql (structured query language). Эту аббревиатуру часто произносят как «си-ку-эл».

Другие сокращения:  Почему у древних римлян везде красовалась аббревиатура «S.P.Q.R.»? | Пикабу

Между ранними прототипами sequel и признанным ныне в различных организациях стандартом sql имеются существенные различия. Джим Мелтон, занимавшийся подготовкой стандарта sql-92, даже заявил, что многие ошибаются, считая, будто слово «структурированные» правильно отражает специфику этого языка (jim melton and alan r. simon «understanding the new sql: a complete guide». san francisco: morgan kaufmann, 1993. isbn: 1-55860-245-3). Поэтому фактически sql — это просто название, последовательность букв s-q-l и ничего более.

Коммерческое признание

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

Однако у реляционных продуктов было большое преимущество. Реализован­ные в них языки реляционных запросов (SQL, QUEL и другие) позволяли выпол­нять запросы к базе данных без написания программ и немедленно получать ре­зультаты. В результате реляционные базы данных постепенно стали использовать­ся в качестве инструментов для поддержки принятия решений.

В мае 1985 года компания Oracle с гордостью объявила о том, что количество инсталляций реля­ционных продуктов ее производства превысило одну тысячу. Ingres к тому време­ни также была инсталлирована на сравнимом количестве компьютеров. Посте­пенно начали получать признание и продукты DB2 и SQL/DS, общее число ин­сталляций которых тоже превысило тысячу.

Во второй половине 1980-х годов реляционные базы данных уже стали считать­ся технологией баз данных будущего. Резко увеличилась производительность ре­ляционных баз данных. В частности, каждая новая версия Ingress и Oracle превос­ходила предшественницу в два-три раза. На увеличении этого показателя сказался и общий рост быстродействия компьютеров.

В конце 1980-х годов росту популярности SQL начали способствовать и рыноч­ные тенденции. Компания IBM продвигала на рынок систему DB2 как лучшее ре­шение 1990-х годов. Опубликование в 1986 году стандарта SQL, принятого ANSI/ISO, официально придало SQL статус стандартного языка баз данных.

Кро­ме того, SQL стал стандартом для компьютерных систем на базе UNIX, популяр­ность которых также росла ускоренными темпами в конце 1980-х годов. По мере увеличения мощности персональных компьютеров и объединения их в локальные сети возникла необходимость в более сложных СУБД.

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

В начале 1990-х годов усовершенствование реализаций SQL и резкое возраста­ние мощи процессоров сделали SQL практичным решением для приложений об­работки транзакций. И наконец, SQL стал ключевой частью архитектуры «клиент/сервер», использующей персональные компьютеры, локальные сети и се­тевые серверы для построения дешевых систем обработки информации.

Однако SQL не испытывал и недостатка в конкуренции. К началу 1990-х годов объектно-ориентированное программирование зарекомендовало себя как наибо­лее перспективный метод разработки приложений, особенно для персональных компьютеров и в области пользовательских графических интерфейсов.

Объектная модель данных, со своими объектами, классами, методами и наследованием, плохо соотносилась с реляционной моделью таблиц, строк и столбцов данных. Ранние «объектные базы данных» включали Gemstone от Servio Logic, Gbase от Graphael и Vbase от Ontologic.

В средине 1990-х годов выросло новое поколение компаний, рассчитывавших на то, что объектные базы данных вытеснят с рынка реляционные базы данных и их производителей, так же как в свое время SQL поступил с нере­ляционными базами данных. Здесь можно упомянуть такие продукты, как ITASCA от Itasca Systems, Jasmine от Fujitsu, Matisse от Matisse Software, Objectivity/DB от Objectivity, ONTOS от Ontos, Inc. (переименованного из Ontologic)

, 02 от 02 Technology, а также с полдесятка других. Ho SQL и реляционная модель более чем устояли перед этим натиском. Некоторые из упомянутых продуктов остались на рынке и сегодня, но большинство было просто куплено или сгинуло во мгле вре­мени. Например, 02 Technology постигла судьба некоторых других компаний, ку­пленных Informix, a Informix, в свою очередь, позже был приобретен IBM.

По мере развития SQL этот язык стал применяться для решения множества за­дач, связанных с управлением данными, и постепенно, к концу 90-х годов, рынок баз данных перестал быть монолитным, разделившись на ряд специализированных сегментов. Одним из наиболее быстрорастущих среди них стал сегмент хранилищ данных, где базы данных применяются для анализа огромных объемов информа­ции на предмет выявления скрытых тенденций и моделей развития.

Другим на­правлением является внедрение в SQL новых типов данных (в частности, мульти­медийных) и объектно-ориентированных принципов. Третий важный сегмент — это «мобильные» базы данных для переносных персональных компьютеров, взаи­модействующие с централизованными базами данных как в оперативном, так и в автономном режиме.

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

Краткая история sql

История SQL тесно связана с развитием реляционных баз данных. В табл. 1 пе­речислены основные вехи его сорокалетней истории. Понятие реляционной базы данных было введено доктором Э. Ф. Коддом (Edgar Frank «Ted» Codd), научным со­трудником компании IBM.

В июне 1970 года доктор Кода опубликовал в журнале Communications of the Association for Computing Machinery статью «Реляционная модель для больших банков совместно используемых данных» («A Relational Model of Data for Large Shared Data Banks»), в которой в общих чертах была изложена ма­тематическая теория хранения данных в табличной форме и их обработки. От этой статьи и берут свое начало реляционные базы данных и SQL.

Год

Событие

1970

Доктор Кода создает модель реляционной базы данных

1974

Начинается разработка проекта System/R компании IBM

1974

Первая статья с описанием языка SEQUEL

1978

Опытная эксплуатация проекта System/R

1979

Появляется первая коммерческая СУРБД компании Oracle

1981

Компания Relational Technology выпускает СУБД Ingres

1981

Компания IBM создает СУБД SQL/DS

1982

ANSI формирует комитет по стандартизации языка SQL

1983

Компания IBM объявляет о создании СУБД DB2

1986

ANSI принимает стандарт SQL1

1986

Компания Sybase создает СУРБД для обработки транзакций

1987

ISO одобряет стандарт SQL1

1988

Компании Ashton-Tate и Microsoft объявляют о выпуске СУБД SQL Server для операционной системы OS/2

1989

Опубликован первый тест производительности ТРС (ТРС-А)

1990

Опубликован тест производительности ТРС-В

1991

Консорциум SQL Access Group публикует спецификацию доступа к базам данных

1992

Компания Microsoft публикует спецификацию протокола ODBC

1992

ANSI принимает стандарт SQL2 (SQL-92)

1992

Опубликован тест производительности ТРС-С (OLTP)

1993

Первые поставки систем обслуживания хранилищ данных

1993

Первые поставки программных продуктов, поддерживающих протокол ODBC

1994

Коммерческие поставки серверов баз данных, поддерживающих параллельную обработку

1995

Первый выпуск СУРБД с открытым кодом MySQL

1996

Опубликован стандарт API-функций для доступа к базам данных OLAP и тест производительно­сти OLAP-систем

1997

Компания IBM выпускает СУБД DB2 Universal Database, унифицировав ее архитектуру для работы на платформах других поставщиков

1997

Ведущие поставщики СУБД объявили о поддержке Java-технологий

1998

Компания Microsoft выпустила СУБД SQL Server 7, обеспечив поддержку корпоративных баз данных для платформы Windows NT

1998

Выпущена СУБД Oracle 8i, ознаменовавшая отход от архитектуры «клиент/сервер” и обеспе­чившая интеграцию баз данных с Интернетом

1998

Первый выпуск базы данных, полностью размещающейся в оперативной памяти

1999

J2EE стандартизовал JDBC-доступ к базам данных со стороны серверов приложений

 1999 Принимается стандарт ANSI/ISO SQL1999 с добавлением в язык объектно-ориентированных конструкций
 2000 Oracle выпускает серверы приложений с интегрированным кешированием баз данных
 2000 Microsoft выпускает SQL Server 2000, предназначенный для приложений уровня предприятия
 2001 В основных СУРБД появляется возможность поддержки XML
 2001IBM покупает Informix
2002IBM обходит Oracle и становится производителем баз данных №1
2003Принят стандарт ANSI/ISO SQL:2003, в который добавлен SQL/XML
2006Принят стандарт ANSI/ISO SQL:2006 с существенным расширением SQL/XML и объектно­ориентированных конструкций
2006Исследования показывают, что Oracle лидирует на рынке
2008Sun Microsystems покупает MySQL АВ
2008Принят стандарт ANSI/ISO SQL:2008
Оцените статью
Расшифруй.Ру