49181 (Структура языка SQL (Structured Query Language))

2016-07-30СтудИзба

Описание файла

Документ из архива "Структура языка SQL (Structured Query Language)", который расположен в категории "". Всё это находится в предмете "информатика" из 1 семестр, которые можно найти в файловом архиве . Не смотря на прямую связь этого архива с , его также можно найти и в других разделах. Архив можно найти в разделе "курсовые/домашние работы", в предмете "информатика, программирование" в общих файлах.

Онлайн просмотр документа "49181"

Текст из документа "49181"












Курсовая работа по дисциплине "Базы данных"

на тему " Структура языка SQL"


Содержание


Введение

1 Понятие базы данных и СУБД

1.1 Предметная область

1.2 Концепция баз данных

1.2.1 Независимость приложений от организации данных во внешней памяти

1.2.2 Эффективность организации данных

1.2.3 Интеграция данных

1.2.4 Что такое база данных

2. Типы данных SQL

2.1 Таблицы SQL

2.2 Структура языка SQL

2.3 Операторы SQL

Заключение

Глоссарий

Список использованных источников

Приложение А


Введение

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

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

Базовым требованием к реляционным СУБД является наличие мощного и в тоже время простого языка, позволяющего выполнять все необходимые пользователям операции. В последние годы таким повсеместно принятым языком стал язык реляционных БД SQL - Structured Query Language (теперь все чаще название языка понимается как Standard Query Language) .

До появления SQL в СУБД (независимо от того, на какой модели они основывались) приходилось поддерживать по крайней мере три языка, которые обычно имели мало общего: язык определения данных (ЯОД), служащий для спецификации структур БД (обычно общую структуру БД называют схемой БД); язык манипулирования данными (ЯМД), позволяющий создавать прикладные программы, взаимодействующие с БД; и язык администрирования БД (ЯАДБ), с помощью которого можно было выполнять служебные действия (например, изменять структуру БД или производить ее настройку с целью повышения эффективности). Кроме того, если требовалось предоставить пользователям СУБД интерактивный доступ к БД, приходилось вводить еще один язык, операторы которого выполняются в диалоговом режиме. Язык SQL позволяет решать все эти задачи.

Следует отметить, что к достоинствам языка SQL относится наличие международных стандартов. Первый международный стандарт был принят в 1989 г., и соответствующая версия языка называется SQL-89. Этот стандарт полностью поддерживается практически во всех современных коммерческих реляционных СУБД (например, в Informix, Sybase, Ingres, DB2 и т.д.). Стандарт SQL-89 во многих частях имеет чрезвычайно общий характер и допускает очень широкое толкование. В этом стандарте полностью отсутствуют такие важные разделы, как манипулирование схемой БД и динамический SQL. Многие важные аспекты языка в соответствии со стандартом определяются в реализации.

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

Осознавая неполноту стандарта SQL-89, на фоне завершения разработки этого стандарта специалисты различных фирм начали работу над стандартом SQL2. Эта работа также длилась много лет, было выпущено несколько проектов стандарта, пока, наконец, в марте 1992 г. не был выработан окончательный проект стандарта (после чего стандарт и соответствующий язык стали называть SQL-92). Этот стандарт существенно более полный и охватывает практически все необходимые для реализации аспекты: манипулирование схемой БД, управление транзакциями и сессиями (сессия - это последовательность транзакций, в пределах которой сохраняются временные отношения), подключение к БД, динамический SQL. Наконец стандартизованы отношения-каталоги БД, что вообще-то не связано с языком непосредственно, но очень сильно влияет на реализацию. Заметим, что в стандарте представлены три уровня языка - базовый, промежуточный и полный. В течение нескольких лет после принятия стандарта производители СУБД, утверждавшие совместимость своих продуктов со стандартом, на самом деле в лучшем случае поддерживали промежуточный уровень языка SQL-92 (естественно, с собственными расширениями). Только в последних выпусках СУБД ведущих производителей обеспечивается совместимость с полным вариантом языка. Наконец, одновременно с завершением работ по определению стандарта SQL-92 была начата разработка стандарта SQL3. Общей точкой зрения ведущих производителей СУБД является то, что будущие продукты, обладая более развитыми возможностями, должны быть совместимы с предыдущими выпусками. Хотя многие разработчики и пользователи реляционных СУБД осознают наличие многих неустранимых недостатков языка SQL, от него теперь уже невозможно отказаться (как невозможно отказаться от использования языка Си в процедурном программировании). Следовательно, нужен новый стандарт языка, обеспечивающий такие очевидно необходимые возможности как определяемые пользователями типы данных, более развитые средства определения таблиц, наличие полного механизма триггеров и т.д. Нужен именно стандарт, а не наличие развитых частных версий языка, поскольку это выгодно и производителям и пользователям СУБД.

1 Понятие базы данных и СУБД

1.1 Предметная область

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

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

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

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

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

Часто класс объектов называют сущностью. Каждая сущность обладает атрибутами. Атрибут – это свойство объекта, характеризующее его экземпляр. Сущность "студент" может иметь атрибуты "имя" , "год рождения", " дата поступления" и т. д. Таким образом сущность можно определить, как множество индивидуальных объектов одного типа (экземпляров), причем все эти объекты различны, т. е. набор атрибутов одинаков, а их значения различны.

1.2 Концепция баз данных

1.2.1 Независимость приложений от организации данных во внешней памяти

Основой любой информационной системы являются хранимые в ней данные. В общем случае данные – это информация, подготовленная для определенных целей, при этом часто подразумевается определенный формат представления.

Во все времена люди фиксировали данные на том или ином материальном носителе (бумага, камень и т. д.) Обычно данные фиксируются совместно с их интерпретацией (семантикой), так как системы письменности естественных языков позволяет это делать достаточно гибко. Например, запись на бумаге "Заработная плата – 1000" содержит данное – "1000" и его семантику (смысл) – "Заработная плата".

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

Применение ЭВМ для обработки и хранения данных привело к еще большему разделению данных и интерпретирующей информации. Так как на ранних этапах развития вычислительной техники ее возможности были весьма ограничены, память использовалась только для хранения самих данных. Описание же данных (порядок, тип данных, длина) находились в программах, которые таким образом "знали", например, что с начиная определенного байта адресного пространства внешней памяти четыре байта содержат данное в числовом формате, связанное с заработной платой, а последующие 30 байтов в текстовом формате – содержат фамилию сотрудника.

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

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

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

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

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

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


1.2.2 Эффективность организации данных

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

Допустим, мы решили создавать эту информационную систему используя некоторую файловую систему, в которой пользователи представляют файл как последовательность записей. Каждая запись – это последовательность байтов постоянного или переменного размера. Записи можно читать или записывать последовательно, позиционировать файл на запись с указанным номером, структурировать на поля и объявлять некоторые поля ключами записи. Кроме того, имеется возможность выборки записи из файла по ее заданному ключу. Естественно, что в этом случае файловая система поддерживает в том же (или другом, служебном) базовом файле дополнительные, невидимые пользователю, служебные структуры данных. Распространенные способы организации ключевых файлов основываются на технике хеширования и B-деревьев.

Для хранения данных будем использовать один файл СТУДЕНТЫ. Поскольку объектом предметной области в нашем случае является студент, определяем, чтобы в этом файле содержалась одна запись для каждого студента. Исходя из требований к информационной системе, обозначим набор свойств, описывающий объект и отразим его следующими полями в файле:

ФИО_СТУДЕНТА,

АДРЕС,

ДАТА_РОЖДЕНИЯ,

НАИМНОВАНИЕ_ФАКУЛЬТЕА,

ФИО_ДЕКАНА,

НОМЕР_ГРУППЫ,

ФИО_КУРАТОРА.

Функции нашей информационной системы требуют, чтобы обеспечивалась возможность многоключевого доступа к записям этого файла по значениям уникального ключа ФИО_СТУДЕНТА. Кроме того, должна обеспечиваться возможность выбора всех записей с общим значением НАИМЕНОВАНИЕ_ФАКУЛЬТЕТА и НОМЕР_ГРУППЫ т. е. доступ по неуникальному ключу.

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

Свежие статьи
Популярно сейчас
Зачем заказывать выполнение своего задания, если оно уже было выполнено много много раз? Его можно просто купить или даже скачать бесплатно на СтудИзбе. Найдите нужный учебный материал у нас!
Ответы на популярные вопросы
Да! Наши авторы собирают и выкладывают те работы, которые сдаются в Вашем учебном заведении ежегодно и уже проверены преподавателями.
Да! У нас любой человек может выложить любую учебную работу и зарабатывать на её продажах! Но каждый учебный материал публикуется только после тщательной проверки администрацией.
Вернём деньги! А если быть более точными, то автору даётся немного времени на исправление, а если не исправит или выйдет время, то вернём деньги в полном объёме!
Нет! Мы не выполняем работы на заказ, однако Вы можете попросить что-то выложить в наших социальных сетях.
Добавляйте материалы
и зарабатывайте!
Продажи идут автоматически
4123
Авторов
на СтудИзбе
667
Средний доход
с одного платного файла
Обучение Подробнее