Управление данными

МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ 
РОССИЙСКОЙ ФЕДЕРАЦИИ 
 
Федеральное государственное бюджетное образовательное учреждение 
высшего образования 
«Ростовский государственный экономический университет (РИНХ)» 
 
 
 
 
 
 
 
 
 
 
 
А.И. Долженко, С.А. Глушенко 
 
 
УПРАВЛЕНИЕ ДАННЫМИ 
 
 
Учебное пособие  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Ростов-на-Дону 
Издательско-полиграфический комплекс РГЭУ (РИНХ) 
2020 

УДК 004.4(075)  
ББК 32.97 
Д 64 
 
 
Долженко, А.И. 
Д 64 
Управление данными : учебное пособие / А.И. Долженко, 
С.А. Глушенко. – Ростов-на-Дону : Издательско-полиграфический комплекс Рост. гос. экон. ун-та (РИНХ), 2020. – 174 с. 
ISBN 978-5-7972-2830-1 
 
 
Учебное пособие посвящено вопросам разработки программных систем 
управления данными на основе систем управления базами данны Microsoft SQL 
Server. Описаны подходы к проектированию реляционных баз данных, конструкции языка Transact-SQL, запросы на добавление, обновление и удаление 
данных, хранимые процедуры и пользовательские функции, табличные выражения и транзакции. Приводятся примеры SQL запросов.  
Предназначено для бакалавров, обучающихся по направлениям «Информационные системы и технологии», «Прикладная информатика», «Программная инженерия» и «Бизнес-информатика». 
 
УДК 004.4(075)  
ББК 32.97 
 
 
 
Рецензенты: 
Е.В. Кириевский, д.т.н., профессор кафедры информационных 
 и измерительных систем и технологий Южно-Российского государственного 
политехнического университета (НПИ) им. М.И. Платова; 
С.М. Щербаков, д.э.н., и.о. зав. кафедрой информационных систем  
и прикладной информатики Ростовского государственного 
 экономического университета (РИНХ). 
 
 
Утверждено в качестве учебного пособия учебно-методическим советом  
Ростовского государственного экономического университета (РИНХ). 
 
 
 
 
ISBN 978-5-7972-2830-1 
© РГЭУ (РИНХ), 2020 
© Долженко А.И., Глушенко С.А., 2020 

ОГЛАВЛЕНИЕ 
Введение ...................................................................................................................... 4 
1. Архитектура баз данных ........................................................................................ 5 
2. Реляционные базы данных .................................................................................. 15 
3. Введение в язык Transact-SQL ............................................................................ 26 
4. Язык Transact-SQL. Соединения. Подзапросы .................................................. 39 
5. Хранимые процедуры и функции ....................................................................... 50 
6. Табличные выражения ......................................................................................... 68 
7. Модификация данных .......................................................................................... 84 
8. Транзакции и параллелизм ................................................................................ 114 
9. SQL Server и XML .............................................................................................. 145 
Заключение .............................................................................................................. 172 
Библиографический список ................................................................................... 173 
 

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

1. 
АРХИТЕКТУРА БАЗ ДАННЫХ 
Обзор эволюции систем управления данными 
В управлении данными можно выделить несколько этапов эволюции. 
Вначале данные обрабатывались вручную. На следующем этапе использовались оборудование с перфокартами и электромеханические машины для сортировки и табулирования миллионов записей. На третьем этапе данные хранились 
на магнитных лентах, и сохраняемые программы выполняли пакетную обработку последовательных файлов. На четвертом этапе было введено понятия 
схемы базы данных и оперативного навигационного доступа к данным. На пятом этапе был обеспечен автоматический доступ к реляционным базам данным 
и была внедрена распределенная и клиент-серверная обработка. Теперь мы находимся в начале шестого поколения систем, которые хранят более богатые типы данных, в особенности, документы, изображения, аудио- и видеоданные. 
Эти системы шестого поколения представляют собой базовые средства хранения для приложений интернета и работы в облаке. 
При управлении данными используются различные модели данных: иерархические, сетевые, реляционные, объектно-ориентированные. Модели данных, языки описания и манипулирования данными постоянно развиваются и 
совершенствуются. 
Быстрое развитие Интернета, систем хранения данных, центров обработки данных, облачных сервисов требует совершенствования систем управления 
данными. 
Следует отметить, что базы данных призваны хранить больше, чем только числа и текстовые строки. Они используются для хранения многих видов 
объектов, которые мы видим в World Wide Web, и связей между этими объектами. Различие между базой данных и остальной частью веб становится неясным. Каждый поставщик баз данных обещает «универсальный сервер», который будет хранить и анализировать все формы данных (все библиотеки классов 
и соответствующие объекты). 
Унификация процедур и данных расширяет традиционную вычислительную модель «клиент – сервер» в двух интересных направлениях:  
 активные базы данных; 
 потоки работ (workflow). 
Активные базы данных самостоятельно выполняют задачи при изменении базы данных. Идея состоит в том, что определенная пользователем процедура-триггер срабатывает, когда состояние базы данных переводит условие 
триггера в true. Используя язык процедур базы данных, проектировщики базы 
данных могут определять предусловия и триггерные процедуры. Например, если в базе данных товаров определен триггер повторного заказа, то база данных 
будет вызывать процедуру повторного заказа данного товара, когда его количество достигнет нижнего порога. Триггеры упрощают приложения, позволяя перенести логику из приложений к данным. Механизм триггеров является мощ

ным способом построения активных баз данных, являющихся самоуправляемыми. 
Потоки работ обобщают типичную модель вычислений запрос-ответ. Поток работ – это сценарий задач, которые должны быть выполнены. Например, 
простое покупательское соглашение состоит из шестишагового потока работ: 
1) 
запрос покупателя; 
2) 
предложение цены; 
3) 
подтверждение; 
4) 
поставка; 
5) 
выписка счета; 
6) 
оплата.  
Системы для составления сценариев, выполнения и управления потоками 
работ становятся общераспространенными. 
Чтобы приблизиться к современному состоянию технологии управления 
данными, имеет смысл описать два крупных проекта управления данными, в 
которых используются предельные возможности сегодняшней технологии. 
Система Earth Observation System/Data Information System (EOS/DIS) агентства 
NASA для хранения всех спутниковых данных. Объем базы данных, включающей данные от удаленных сенсорных датчиков, растет на 5 Тбайт в день (терабай – это миллион гигабайт). Размер базы данных превышает 15 петабайт. Это в 
тысячу раз больше объема самых больших сегодняшних оперативных баз данных. NASA желает, чтобы эта база данных была доступна каждому в любом 
месте в любое время. Любой человек сможет производить поиск, анализ и визуализацию данных из этой базы данных. Для построения EOS/DIS используются развитые методы хранения, управления, поиска и визуализации данных. 
Большая часть данных обладает пространственными и временными характеристиками.  
Другим впечатляющим примером базы данных является возникающая 
всемирная библиотека. Многие ведомственные библиотеки открывают доступ к 
своим хранилищам в режиме online. Новая научная литература публикуется в 
режиме online. Такой вид публикации поднимает трудные социальные вопросы 
по поводу авторских прав и интеллектуальной собственности и заставляет решать глубокие технические проблемы. Пугают размеры и многообразие информации. Информация появляется на многих языках, во многих форматах 
данных и в громадных объемах. При применении традиционных подходов к организации такой информации (автор, тема, название) не используются мощности компьютеров для поиска информации по содержимому, для связывания документов и для группирования сходных документов. Обнаружение информации, нахождение требуемой информации в море документов, карт, фотографий, 
звука и видео представляет собой захватывающую и трудную проблему. 
Программное обеспечение управления данными развивалось параллельно 
с развитием аппаратных средств. Системы, ориентированные на записи и наборы, открыли дорогу реляционным системам, которые теперь эволюционируют к 
объектно-реляционным системам.  

В сообществе баз данных имеется согласие по поводу основных задач и 
состава необходимых исследовательских работ. Каждые пять лет сообщество 
баз данных производит самооценку, в которой очерчивается класс первоочередных задач. В последней такой самооценке выделяются следующие задачи: 
 определение моделей данных для новых типов (например, пространственных, темпоральных, графических) и их интеграция с традиционными системами баз данных; 
 масштабирование баз данных по размеру (до петабайт), пространственному размещению (распределенные) и многообразию (неоднородные); 
 автоматическое обнаружение тенденций данных, их структур и аномалий (интеллектуальный анализ данных); 
 интеграция (комбинирование) данных из нескольких источников; 
 создание сценариев и управление потоком работ (процессом) и данными в организациях; 
 автоматизация проектирования и администрирования баз данных.  
Это трудные проблемы. Их решение сделают доступными для частных 
лиц и организаций новые компьютерные приложения. Эти системы позволят 
нам иметь доступ ко всей информации и анализировать ее из любого места в 
любое время. Этот облегченный доступ к информации изменит способы ведения научной деятельности, способы управления бизнесом, способы обучения и 
развлечения. Он и обогатит, и усилит нас и грядущие поколения. 
Возможно, наиболее сложной проблемой является понимание данных. Не 
так уж трудно обеспечить оперативный доступ к большей части данных – поскольку хранение данных в компьютерах стоит недорого и поскольку хранить 
данные в компьютерах удобно. Реальной проблемой, встающей перед нами, является такая организация этих огромных архивов данных, которая позволила бы людям легко находить требующуюся им информацию. Нахождение в большой базе 
данных структур, тенденций, аномалий и релевантной информации является одной из новых, наиболее впечатляющих областей управления данными.  
Классическая архитектура системы баз данных 
Классическая архитектура системы баз данных включает три уровня: 
внутренний, внешний и концептуальный (рис. 1). 
 
Пользователь 1
Пользователь 2
Пользователь n
Концептуальный 
уровень
Внутренний 
уровень
Внешний уровень
 
Рисунок 1.1 – Архитектура системы баз данных 

Внутренний уровень (физический) определяется способами хранения 
информации на физическом устройстве и возможностями операционной системы по работе с данными.  
Концептуальный уровень (логический) представляет обобщенное абстрактное представление данных для различных пользователей. 
Внешний уровень (уровень представления) определяется способами 
представления данных для отдельных пользователей (приложений). 
Внешний уровень предоставляет сервисы для пользователей системы баз 
данных и определяет представление данных в системе. Представление данных 
для каждого приложения может быть различным в зависимости от требований 
конечного пользователя, программной платформы приложения и языка программирования. Следует отметить, что для уровня представления не важна физическая организация данных. Особое место среди пользователей занимает администратор базы данных, которого важны вопросы и логической и физической организации данных.  
Для взаимодействия пользователей с базой данных используются языки 
описания и манипулирования данными. Эти языки не зависят от внутренней 
организации данных. Универсальным языком описания и манипулирования 
данными является язык SQL. В приложениях, взаимодействующих с базами 
данных, в базовый язык включают подъязык данных, который содержит подмножество операторов работы с объектами баз данных и операций с ними. Такой подъязык должен реализовывать функции определения и обработки данных. Для платформы Microsoft.Net приложения могут взаимодействовать с различными базами данных с помощью языка интегрированных запросов LINQ 
(Language Integrated Query), который обеспечивает доступ к широкому разнообразию источников данных для программных приложений на языках C#, C++ 
и Visual Basic.Net. 
Концептуальный уровень – это представление всей информации о базе 
данных на логическом уровне, который является более абстрактным по отношению к физическому способу хранения данных. 
Концептуальное представление состоит из некоторого множества экземпляров каждого из существующих типов концептуальных записей. Например, 
оно может состоять из набора экземпляров записей, содержащих информацию 
об отделах, набора экземпляров записей, содержащих информацию о поставщиках, набора экземпляров записей, содержащих информацию о материалах, и 
т.д. Концептуальная запись вовсе не обязательно должна совпадать с внешней 
записью, с одной стороны, и с хранимой записью – с другой стороны. 
Концептуальное представление определяется с помощью концептуальной 
схемы, включающей определения для каждого существующего типа концептуальной записи. Концептуальная схема использует концептуальный язык, который характеризует содержание информации. Концептуальная схема должна 
обеспечивать независимость данных в том смысле, что внешние схемы, определенные на основе концептуальной, заведомо будут обеспечивать независимость 
данных. 

Концептуальное представление – это представление всего содержимого 
базы данных, а концептуальная схема – это определение такого представления. 
Программные платформы могут предоставлять функциональность на 
концептуальном уровне для взаимодействия приложений с базами данных. 
Платформа Microsoft.Net включает компонент Entity Framework (EF), который 
предоставляет возможность объектно-ориентированным приложениям взаимодействовать с реляционными базами данных посредством манипулирования 
сущностями концептуальных моделей, используя пакеты запросов SQL или запросов LINQ, которые в свою очередь генерируют последовательности операторов SQL. 
Внутреннее представление – это низкоуровневое представление всей базы данных как базы, состоящей из некоторого множества экземпляров каждого 
из существующих типов внутренних записей. Внутреннее представление предполагает наличие бесконечного линейного адресного пространства. Особенности методов отображения этого адресного пространства на физические устройства хранения в значительной степени зависят от используемой операционной 
системы. 
Администратор базы данных 
Важную роль в организации и поддержании работоспособности базы 
данных выполняет администратор базы данных. Администратор базы данных 
(АБД) – это роль, в функции которой входит техническая поддержка системы 
баз данных. Функциями АБД являются: 
 определение концептуальной схемы. Администратор данных решает, 
какая информация должна храниться в базе данных, т.е. определяет набор сущностей, определяет их типы. Этот процесс называется логическим проектированием базы данных. После того как содержимое базы данных на абстрактном 
уровне будет определено, АБД создает соответствующую концептуальную 
схему, использую концептуальный язык определения данных;   
 определение внутренней схемы. Администратор базы данных должен 
решить, как данные будут представлены в хранимой базе данных. Этот процесс 
называется физическим проектированием базы данных. Результатом физического проектирования базы данных является структура хранения данных, для 
создания которой используется внутренний язык определения данных; 
 взаимодействие с пользователями. Администратор базы данных определяет данные, требуемые каждой группе пользователей, создавая внешние 
схемы данных. Для этого создается отображение между созданными внешними 
схемами и концептуальной схемой; 
 определение требований защиты и обеспечение целостности данных. 
Требования защиты и целостности данных определяются на концептуальном 
уровне. Концептуальный язык определения данных должен включать средства 
определения таких требований; 
 определение процедур резервного копирования и восстановления данных. Администратор базы данных должен разрабатывать и реализовывать схе

му восстановления данных, включая периодическую выгрузку данных на устройства резервного копирования и процедуры загрузки данных из резервной 
копии; 
 управление производительностью и реагирование на изменение требований. Администратор базы данных отвечает за такую организацию системы, 
которая обеспечивает заданную производительность, а также за корректировку 
работы системы в соответствии с изменяющимися требованиями. Например, 
может возникнуть необходимость в периодической реорганизации хранимой 
базы данных с целью получения гарантий того, что производительность системы будет поддерживаться на заданном уровне. Любые изменения на физическом уровне хранения данных должны сопровождаться соответствующими изменениями в определении отображений на концептуальном уровне. 
Архитектура обработки данных 
Общее назначение систем баз данных – это поддержка и выполнение 
приложений баз данных. Таким образом, базы данных редко используются сами по себе – они служат основой приложений (транзакционных или аналитических) и встроены в сложные системные архитектуры. Классическая архитектура состоит из трех звеньев, или уровней: презентационного, уровня приложений 
и уровня данных (рис. 2, а). Каждый из уровней предоставляется в виде сервиса 
и обычно размещен на одном или более выделенных серверах. Такая многозвенная система имеет немало преимуществ. В многоуровневых системах на 
каждом из уровней проще выполнять масштабирование, тиражирование, секционирование и кэширование. Более того, путем переноса вычислений с уровня 
данных на уровень приложений или на презентационный можно снизить нагрузку на первый. Уровни приложений и презентационный проще масштабировать, так как они могут быть реализованы в качестве сервисов без сохранения 
состояния: администраторы могут повышать масштабируемость и отказоустойчивость путем горизонтального масштабирования (добавления новых машин), не заботясь о сложных протоколах синхронизации. Однако уровень баз 
данных – это сервис, сохраняющий состояние, и его горизонтальное масштабирование требует более сложных управляющих архитектур (например, «ведущий-ведомый»), а также протоколов обеспечения целостности данных (например, протокола двухфазного подтверждения). Соответственно, на уровне баз 
данных высокой масштабируемости и отказоустойчивости достичь сложнее. 
Дополнительно ухудшает ситуацию то, что, поскольку базы данных 
обычно реализуются как монолитные системы, их масштабирование может 
быть только вертикальным (когда сервер оснащается более мощным оборудованием), а это подразумевает ограничения на готовность и масштабируемость.  
Для устранения недостатков трехуровневой архитектуры, представленной 
на рисунке 1.2, была предложена пятиуровневая архитектура: презентационный 
уровень, приложение, база данных, менеджер записей и файловая система 
(рис. 1.2, б). В новых системах эти уровни (слои) по-разному комбинируются; 
каждый слой представляет собой сервис с возможностью независимого мас