Курсовая работа (т): Язык структурированных запросов SQL. Использование SQL в прикладном программировании

) Выполнение основных функций как с БД, так и с содержащимися в ней данными: создание, редактирование архитектуры, удаление БД; добавление отношений, заполнение отношений данными, удаление данных, считка, редакция.

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

) Все крупные СУБД имеют версии для ЭВМ с разной архитектурой и для разных операционных систем. Это позволяет использовать один продукт в работе с БД, даже если компьютеры в системе значительно отличаются программно и архитектурно. К примеру, имея сервер с ОС семейства Unix и несколько пользовательских компьютеров с Windows, можно использовать одну и ту же СУБД на всех узлах системы.

) Так как в большинстве случаев доступ к базе данных имеют несколько узлов системы, СУБД имеют широкие возможности в контроле доступа к данным (система защиты данных через проверку привилегий пользователя и так далее; контроль параллельного доступа к БД для упорядочивания редакции данных; системы восстановления утерянных данных) [4, с. 12]

Все вышеописанные возможности исходят из функций, возможность выполнения которых требуется от полноценной СУБД:

l  Поддержка языков баз данных. Всякая СУБД должна поддерживать один (как правило) язык управления базами данных.

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

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

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

l  Управление буферами в оперативной памяти.

l  Контроль доступа к БД.

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

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

Рисунок 2: Три уровня архитектуры СУБД

Как видно из схемы на рисунке 2, СУБД включает в себя все три уровня архитектуры: внешний, отвечающий за пользовательские представления (ПП1, ПП2 и так далее на рисунке), внутренний уровень работает напрямую с банком данных, то есть, с данными БД, а концептуальный уровень реализует трансляцию запросов, полученных с внешнего уровня, на внутренний и преобразует данные, возвращаемые с внутреннего уровня, в такой вид, который затем внешним уровнем может быть представлен в понятном для пользователя формате [4, с. 16].

Наиболее распространенные СУБД (работающие с реляционными базами данных) включают: MS Access, MySQL, SQLite, Firebird и другие. На рисунках 3-5 приведен внешний вид основного окна некоторых из этих СУБД.

Рисунок 3: Основное окно MS Access 2013 (с открытой базой данных)

Рисунок 4: главное окно FlameRobin - популярного графического интерфейса СУБД Firebird

Рисунок 5: Главное окно MySQL Workbench - средства работы с MySQL

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

.3 Реляционные БД: отношения, реляционные операции, ключи

Главным элементом реляционных БД, вынесенным, собственно, в название, является отношение (англ. relation). Математически отношение - это подмножество декартова произведения. Следует отметить, что глубокая связь с теорией множеств у реляционных БД на этом не исчерпывается - сама реляционная алгебра черпает многие свои элементы именно из теории множеств.

Однако на практике термин «отношение» почти не используется и заменяется на «таблицу». Однако в случае реляционных БД различие несущественно, и по сути отношение можно принять за таблицу в контексте практики: некое количество m комбинаций n различных признаков образует отношение. В таком случае n признаков будут столбцами таблицы, а m комбинаций - ее строками [11, с. 32].

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

Данные в таблицах должны удовлетворять следующим условиям:

l  Каждое значение, лежащее на пересечении строки и столбца, должно являться атомарным (не разбиваемым на несколько значений).

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

l  Каждая запись в таблице должна быть уникальна.

l  Название каждого поля должно быть уникально.

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

Все реляционные операции (операторы) являются аналогами операций в теории множеств:

) Объединение отношений - выражается формулой R = R1∨R2, где R1 и R2 - два отношения, а R - результирующее отношение, содержащее все записи, которые есть в R1 и в R2.

) Пересечение отношение - выражается формулой R = R1∧R2, где R1 и R2 - два отношения, а R - результирующее отношение, содержащее только те записи, которые есть и в R1, и в R2 одновременно.

) Разность отношений - выражается формулой R = R1|R2, где R1 и R2 - два отношения, а R - результирующее отношение, содержащее только те записи, которые есть в R1, но отсутствуют в R2.

) Произведение отношений - выражается формулой R = R1×R2, где R1 и R2 - два отношения, а R - результирующее отношение, содержащее все возможные комбинации записей из первого отношения и второго отношения. Порядок полей при этом не играет роли.

) Проекция отношения на компоненты - это операция, заключающаяся в выборке определенных столбцов из отношения R1 и построения из них нового отношения R со столбцами в указанном порядке.

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

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

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

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

Изучив основные понятия баз данных в целом, реляционных баз данных и систем управления базами данных, можно переходить к основному предмету работы - языку SQL и возможностям использования его в программировании, но перед этим следует сделать отступление, дабы получить представление о теоретической части проектирования реляционной БД.

.4 Проектирование базы данных. Язык UML

прикладной программирование язык база

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

Главной задачей на этапе проектирования является наиболее точное отражение реалий тех объектов, которые будут отражены в базе данных. Для этого используются так называемые «семантические модели». Одной из популярных семантических моделей является «сущность - связь». Главными элементами такой модели являются сущности, их атрибуты и типы связей. Модель «сущность - связь» оказалась чрезвычайно эффективным инструментом трансляции абстрагированных объектов реального мира, которые должны быть перенесены в базу данных, на уровень концепции, дабы затем концептуальную модель трансформировать в реальную БД. Эффективность этого подхода заключается в том, что элементы его подробно отражают как фактическую, так и логическую суть нужных объектов.

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

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

При построении графической модели сущность указывается как прямоугольник, атрибут сущности - как прямоугольник со скругленными краями, а связь - как ромб. При этом атрибуты и связи соединены с сущностями прямыми линиями (рисунок 6) [4, с.36].

Рисунок 6: Графическое представление концептуальной модели «сущность - связь»

В концепции «сущность - связь» используются следующие важные параметры:

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

Показатель кардинальности - это количество возможных связей для каждого экземпляра, который участвует в связи сущности. Показатель кардинальности может принимать следующие значения: один к одному (1:1), один ко многим (1:N), многие к одному (N:1), многие ко многим (M:N) [4, с. 37].

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

Для проектирования реляционных БД UML предлагает классовые диаграммы, которые содержат в себе классы (аналог сущности), атрибуты этих классов (аналог атрибута сущности) и связи между классами. Пример простейшей концептуальной модели, созданной на языке UML (программа Violet UML Editor), представлен на рисунке 7:

Рисунок 7: Простейшая концептуальная модель реляционной БД на языке UML

2. СТРУКТУРИРОВАННЫЙ ЯЗЫК ЗАПРОСОВ SQL

.1 Введение в SQL. Основные понятия

Говоря о реляционных базах данных, невозможно не уделить внимание языку структурированных запросов SQL, который являет одним из наиболее популярных, многофункциональных и удобных инструментов обращения к реляционным БД.

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

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

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

l  PL/SQL - используется в СУБД Oracle

l  Transact-SQL - используется в СУБД Microsoft SQL

l  Jet SQL - используется Microsoft Access

Популярная бесплатная СУБД Firebird имеет несколько диалектов SQL, которые можно использовать для разных БД под ее управлением.