SQL_LektsiiRus

Введення в бази даних и SQL

1.1Введение в базы данных

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

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

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

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

1.2Архитектура SQL Server 2005

SQL Server 2005 является сервером баз данных третьего поколения от компании Microsoft. SQL Server 2005это широкий набор средств и инструментов работы с данными.

Архитектура SQL Server затрагивает такие концепции, как организация страниц данных и индексов, планирования и кэширования

запросов, а также оптимизатора запросов. SQL Server поддерживает следующие архитектуры:

-клиент/сервер;

-многоуровневую;

-основанную на службах.

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

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

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

Архитектура, ориентированная на службы (SOA), является альтернативой клиент-серверной архитектуре. Вместо программирования прикладного интерфейса «клиент/сервер» между несколькими системами, SOA использует стандартные вызовы HTTP и XML, позволяя множеству систем взаимодействовать с одной, используя один и тот же интерфейс.

1.3Модель баз данных ―клиент/сервер‖

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

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

Вбазах данных архитектуры ―клиент/сервер‖ сервер баз данных обслуживает запросы к базе от клиентского процесса.

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

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

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

Сервер баз данных отвечает за следующее:

- обработка запросов на извлечение и модификацию данных; - интенсивная обработка данных; - поддержание всех правил и ограничений базы данных;

- поддержание безопасности базы данных. Клиентский процесс отвечает за следующее:

- представление данных пользователю в понятном и удобном формате;

- обеспечение интерфейса пользователя всевозможными инструментами, данными и отчетами;

- отправку запросов серверу.

1.4Нормализация данных

Впервые в 1969 году Э.Ф. Кодд сформулировал определение базы данных как объекта, ―состоящего из совокупности неупорядоченных таблиц, к которым могут применяться непроцедурные операции, возвращающие таблицы‖. Из этого определения базы данных следуют следующие важные выводы:

1.Порядок строк в таблицах не имеет значения.

2.Должна быть предусмотрена возможность применять к таблицам реляционные операции (в своей работе Кодд называл таблицы ―отношениями‖ — relation).

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

SQL Server 2005 относится к реляционным базам данных. Реляционные базы данных собирают однообразные или связанные данные в единый список (таблицу). Например, информация о товарах может быть перечислена в одной таблице, а о клиентах – в другой.

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

Изображение различных сущностей (экземпляров данных) и связей (родительски-дочерних зависимостей между экземплярами данных) обычно называют диаграммами ―сущность—связь‖ (или ЕR - диаграммами). Иногда вместо термина ―ЕR-диаграмма‖ применяется сокращенное обозначение ЕRD

(ЕR-Diagram).

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

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

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

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

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

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

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

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

1.Таблица должна представлять одну и только одну сущность (не допускается никаких попыток удаления части атрибутов одной сущности и добавления атрибутов другой сущности).

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

3.Порядок расположения столбцов и строк не должен иметь значения. Таким образом, необходимо, прежде всего, правильно определить

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

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

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

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

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

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

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

Пример данных, содержащихся в заказах: номер заказа, дата заказа, Ф.И.О. клиента, адрес клиента, телефон клиента, строка заказа (наименование товара, единица измерения, цена, количество), общая сумма заказа.

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

Теперь можно заняться осуществлением процесса нормализации.

Первая нормальная форма

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

Из-за повторяющихся групп данных возникают следующие проблемы:

1.Из-за того, что одинаковые данные повторно записывались на внешнее устройство по нескольку раз, значительный объем пространства на диске затрачивался впустую.

2.Чем больше повторяющихся данных, тем больше объем перемещаемых данных и больше количество операций вводавывода. Это означает, что в связи с необходимостью передавать по шине данных и (или) по сети крупные блоки данных снижается производительность. Указанный фактор может оказывать весьма заметное отрицательное влияние на производительность, даже несмотря на то, что современные технические средства обладают высоким быстродействием.

3.Если в разных строках с данными встречаются повторяющиеся данные, то такие данные часто не согласуются, по той причине, что

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

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

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

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

Таблица 1.2. Таблица «Заказы» с данными

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

Исключим из таблицы «Заказы» три столбца о клиентах: «Ф.И.О. клиента», «Адрес клиента» и «Телефон клиента» и поместим их в таблицу «Клиенты».

Для новой таблицы «Клиенты» необходимо предусмотреть первичный ключ, чтобы обеспечить уникальность данных в каждой строке. Для таблицы «Клиенты» с данными о заказчиках может быть предложен ключ «Ф.И.О. клиента». Но нельзя исключить такую возможность, что в столбце «Ф.И.О. клиента» появится информация о заказчикаходнофамильцах, поэтому, чтобы однозначно идентифицировать клиента введем для него номер, который будет уникальным для каждого клиента. Поэтому столбец «Номер клиента» будет использоваться в качестве столбца первичного ключа.

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

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