Информационное обеспечение систем управления

 

 

УДК 681.3.06 

В-19 

Балакина Е. П., Васильева М. А., Филипченко К. М. Информационное обеспечение систем 

управления. Методические указания к курсовому проектированию. Учебно-методическое 

пособие. Издание второе, исправленное и дополненное, 2023. 102 –с. 

 

В учебно-методическом пособии рассмотрена реляционная модель данных, метод 

проектирования реляционных баз данных «Сущность-связь» и метод нормализации 

отношений. Описана работы с применением системы контроля версий. Приведен порядок 

составления отчета. 

Учебно-методическое пособие предназначено для обучающихся по направлению 

«Управление в технических системах» профиля «Управление и информатика в 

технических 
системах» 
(27.03.04), 
а 
также 
обучающихся 
по 
специальности 

«Компьютерная безопасность» специализации «Информационная безопасность объектов 

информатизации на базе компьютерных систем» (10.05.01). 

 

 

 

Рецензент: 

к. т. н., доцент кафедры «Автоматика, телемеханика и связь на железнодорожном 

транспорте» РУТ (МИИТ) Ваньшин А. Е. 

 

 

 

 

 

 

 

© Балакина Е. П., 2023 

© Васильева М. А., 2023 

© Филипченко К. М., 2023 

ЦЕЛЬ КУРСОВОГО ПРОЕКТА 

Целью курсового проекта является изучение методов и закрепление 

знаний в проектировании реляционных баз данных (РБД) в системе 

управления базами данных (СУБД) Microsoft SQL Server. 

ЗАДАНИЕ НА КУРСОВОЙ ПРОЕКТ 

В данном курсовом проекте ставится задача разработать РБД в СУБД 

Microsoft SQL Server по заданной теме, формализующую заданную 

предметную область (ПрО, domain). Проектирование РБД проводится с 

помощью метода «Сущность-связь». Проверка построенной модели РБД 

осуществляется 
с 
помощью 
метода 
нормализации 
отношений 
[1]. 

Пояснительная записка должна содержать пункты по проектированию РБД и 

пункты по разработке РБД в СУБД Microsoft SQL Server: разработка 

скриптов на создание и заполнение РБД, разработка необходимых функций, 

процедур, триггеров и представлений (views). 

Пояснительная записка оформляется согласно ГОСТ 7.32–2017 

«ОТЧЕТ О НАУЧНО-ИССЛЕДОВАТЕЛЬСКОЙ РАБОТЕ» [2]. Пример 

титульного листа представлен в ПРИЛОЖЕНИЕ A. 

 
 

ПОНЯТИЕ РЕЛЯЦИОННОЙ МОДЕЛИ ДАННЫХ 

Реляционная 
модель 
данных 
основывается 
на 
математических 

принципах, которые вытекают из теории множеств и математической логики 

(раздел исчисления предикатов) [3]. Эти принципы впервые были применены 

в области моделирования данных в конце 1960-х годов доктором 

Е. Ф. Коддом, а впервые опубликованы – в 1970 году [4], [5]. Тогда же 

появились первые прототипы реляционных систем управления базами 

данных 
(СУБД). 
Долгое 
время 
считалось 
невозможным 
добиться 

эффективной реализации таких систем. Постепенное накопление методов и 

алгоритмов организации реляционных баз данных и управления ими привели 

к тому, что уже в середине 80-х годов реляционные системы практически 

вытеснили с мирового рынка ранние СУБД (иерархические и сетевые) [6]. 

Техническая статья «Реляционная модель данных для больших 

разделяемых банков данных» доктора Е. Ф. Кодда, опубликованная в 1970 г., 

является родоначальницей современной теории реляционных БД [5]. Доктор 

Кодд определил 12 правил реляционной модели (которые называют 

12 правилами Кодда) [4]. 

12 правил Кодда 

Реляционная СУБД должна быть способна полностью управлять базой 

данных через ее реляционные возможности: 

1. Информационное правило – вся информация в РБД (включая имена 

таблиц и столбцов) должна определяться строго как значения в 

таблицах. 

2. Гарантированный доступ – любое значение в РБД должно быть 

гарантированно доступно для использования через комбинацию 

имени таблицы, значения первичного ключа и имени столбца. 

3. Поддержка пустых значений (null value) – СУБД должна уметь 

работать 
с 
пустыми 
значениями 
(неизвестными 
или 

неиспользованными значениями), в отличие от значений по 

умолчанию и независимо для любой ПрО. 

4. Онлайновый реляционный каталог – описание РБД и ее содержания 

должны быть представлены на логическом уровне как таблицы, к 

которым можно применять запросы, используя язык базы данных. 

5. Исчерпывающий язык управления данными – по крайней мере, 

один 
из 
поддерживаемых 
языков 
должен 
иметь 
четко 

определенный синтаксис и быть всеобъемлющим. Он должен 

поддерживать описание структуры данных и манипулирование ими, 

правила целостности, авторизацию и транзакции. 

6. Правило обновления представлений (views) – все представления, 

теоретически обновляемые, могут быть обновлены через систему. 

7. Вставка, обновление и удаление – СУБД поддерживает не только 

запрос на отбор данных, но и вставку, обновление и удаление. 

8. Физическая независимость данных – на программы-приложения и 

специальные 
программы 
логически 
не 
влияют 
изменения 

физических методов доступа к данным и структур хранилищ 

данных. 

9. Логическая независимость данных – на программы-приложения и 

специальные программы логически не влияют, в пределах 

разумного, изменения структур таблиц. 

10. Независимость целостности – язык РБД должен быть способен 

определять правила целостности. Они должны сохраняться в 

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

обойти. 

11. Независимость распределения – на программы-приложения и 

специальные программы логически не влияет, первый раз 

используются данные или повторно. 

12. Неподрывность – невозможность обойти правила целостности, 

определенные через язык базы данных, использованием языков 

низкого уровня. 

Кодд предложил применение реляционной алгебры к системе 

управления реляционной базой данных (СУРБД), для разбиения данных в 

связанные наборы. Он организовал свою СУБД вокруг теории, основанной на 

наборах данных. 

Самая распространенная трактовка реляционной модели данных 

принадлежит известному последователю идей Кодда Кристоферу Дейту [3]. 

Согласно трактовке Дейта, реляционная модель состоит из трех частей, 

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

манипуляционной части и целостной части. 

В структурной части модели фиксируется, что единственной родовой 

структурой данных, используемой в РБД, является нормализованное n-арное 

отношение (кортеж). Определяются понятия domain атрибутов, кортежей, 

заголовка, тела и переменной отношения [7]. 

В манипуляционной части модели определяются два фундаментальных 

механизма манипулирования РБД – реляционная алгебра и реляционное 

исчисление. Первый механизм базируется на классической теории множеств, 

а второй – на классическом логическом аппарате исчисления предикатов 

первого порядка. Основной функцией манипуляционной части реляционной 

модели является обеспечение меры реляционности любого конкретного 

языка РБД: язык называется реляционным, если он обладает не меньшей 

выразительностью и мощностью, чем реляционная алгебра [8] или 

реляционное исчисление [9]. 

Ограничения целостности 

Три типа ограничений целостности являются неотъемлемой частью 

реляционной модели данных: целостность объекта, ссылочная целостность и 

целостность домена. 

Целостность сущности 

Первое требование называется требованием целостности сущности 

(entity integrity). Объекту или сущности реального мира в РБД 

соответствуют кортежи отношений. Конкретно требование состоит в том, что 

любой кортеж любого значения-отношения любой переменной отношения 

должен быть отличим от любого другого кортежа этого значения отношения 

по составным значениям заранее определенного множества атрибутов 

переменной отношения, т. е. любая переменная отношения должна 

обладать 
первичным 
ключом. 
Это 
требование 
автоматически 

удовлетворяется, если в системе не нарушаются базовые свойства 

отношений. 

Целостность ссылок 

Ссылочная 
целостность 
(eferential 
integrity) 
касается 

концепции внешнего ключа (foreign key). Связи между данными, 

хранимыми в разных отношениях, в реляционной БД устанавливаются с 

помощью использования внешних ключей – для установления связи между 

кортежем из отношения A с определённым кортежем отношения B в 

предусмотренные для этого атрибуты кортежа отношения A записывается 

значение первичного ключа (а в общем случае значение потенциального 

ключа) целевого кортежа отношения B. Таким образом, всегда имеется 

возможность выполнить две операции [10]: 

 определить, с каким кортежем в отношении B связан определённый 

кортеж отношения A; 

 найти все кортежи отношения A, имеющие связи с определённым 

кортежем отношения B. 

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

избыточного дублирования, то есть в нормализованном виде. Ссылочная 

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

Дана пара отношений A и B, связанных внешним ключом. Первичный 

ключ отношения B – атрибут B.key. Внешний ключ отношения A, 

ссылающийся на B – атрибут A.b. Ссылочная целостность для пары 

отношений A и B имеет место тогда, когда выполняется условие: для каждого 

кортежа отношения A существует соответствующий кортеж отношения B, то 

есть кортеж, у которого (B.key = A.b). 

База данных обладает свойством ссылочной целостности, когда для 

любой пары связанных внешним ключом отношений в ней условие 

ссылочной целостности выполняется. 

Если вышеприведённое условие не выполняется, говорят, что в базе 

данных нарушена ссылочная целостность. Такая БД не может нормально 

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

зависимыми друг от друга фактами. Непосредственным результатом 

нарушения ссылочной целостности становится то, что корректным запросом 

не всегда удаётся получить корректный результат. 

Целостность домена 

Домен (domain) – это набор всех допустимых значений, которые 

может содержать атрибут. Понятие «домен» часто путают с понятием «тип 

данных». Необходимо различать эти два понятия. Тип данных – это 

физическая концепция, а домен – логическая. Например, «целое число» – это 

тип данных, а «возраст» – это домен, ограничение, накладываемое ПрО на 

данный атрибут. 

Ограничение домена – ограничения на значения атрибутов из 

множества значений домена. Если значения атрибута неизвестно, то значение 

атрибута – NULL. 

Транзакции 

Чтобы обеспечить целостность сущностей и ссылок у СУБД имеется 

механизм 
транзакций. 
Транзакция 
– 
это 
минимальная 
логически 

осмысленная операция, которая может быть выполнена только полностью. 

Свойства транзакций 

Одним из наиболее распространённых наборов требований к 

транзакциям 
и 
транзакционным 
системам 
является 
набор 
ACID 

(Atomicity, Consistency, Isolation, Durability). Набор данных 

требований к транзакционной системе, обеспечивающий наиболее надёжную 

и предсказуемую её работу – атомарность, согласованность, изоляция, 

устойчивость были сформулированы в конце 1970-хх Джимом Греем [11]. 

Атомарность 

Атомарность 
гарантирует, 
что 
никакая 
транзакция 
не 
будет 

зафиксирована в системе частично. Будут либо выполнены все её 

подоперации, либо не выполнено ни одной. Поскольку на практике 

невозможно одновременно и атомарно выполнить всю последовательность 

операций внутри транзакции, вводится понятие «отката» (rollback): если 

транзакцию не удаётся полностью завершить, результаты всех её до сих пор 

произведённых действий будут отменены и система вернётся во «внешне 

исходное» состояние – со стороны будет казаться, что транзакции и не было 

(естественно, счётчики, индексы и другие внутренние структуры могут 

измениться, но, если СУБД запрограммирована без ошибок, это не повлияет 

на внешнее её поведение). 

Согласованность 

Транзакция, достигающая своего нормального завершения (англ. end 

of transaction, EOT) и тем самым фиксирующая свои результаты, 

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

транзакция по определению фиксирует только допустимые результаты. Это 

условие является необходимым для поддержки четвёртого свойства. 

Согласованность является более широким понятием. Например, в 

банковской системе может существовать требование равенства суммы, 

списываемой с одного счёта, сумме, зачисляемой на другой. Это – бизнес-

правило, и оно не может быть гарантировано только проверками 

целостности, его должны соблюсти программисты при написании кода 

транзакций. Если какая-либо транзакция произведёт списание, но не 

произведёт зачисления, то система останется в некорректном состоянии и 

свойство согласованности будет нарушено. 

Наконец, ещё одно замечание касается того, что в ходе выполнения 

транзакции согласованности не требуется. В нашем примере списание и 

зачисление будут, скорее всего, двумя разными подоперациями, и между их 

выполнением внутри транзакции будет видно несогласованное состояние 

системы. Однако не нужно забывать, что при выполнении требования 

изолированности 
(см. 
ниже) 
никаким 
другим 
транзакциям 
эта 

несогласованность не будет видна. А атомарность гарантирует, что 

транзакция либо будет полностью завершена, либо ни одна из операций 

транзакции 
не 
будет 
выполнена. 
Тем 
самым 
эта 
промежуточная 

несогласованность является скрытой. 

Изоляция 

Во время выполнения транзакции параллельные транзакции не должны 

оказывать влияния на её результат. Изолированность – требование дорогое, 

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

изолирующие 
транзакцию 
(уровни 
изолированности, 
допускающие 

фантомное чтение и ниже). 

Устойчивость 

Независимо от проблем на нижних уровнях (к примеру, обесточивание 

системы или сбои в оборудовании) изменения, сделанные успешно 

завершённой 
транзакцией, 
должны 
остаться 
сохранёнными 
после 

возвращения системы в работу. Другими словами, если пользователь 

получил подтверждение от системы, что транзакция выполнена, он может 

быть уверен, что сделанные им изменения не будут отменены из-за какого-

либо сбоя. 

Уровни изоляции транзакций 

В идеале транзакции разных пользователей должны выполняться так, 

чтобы создавалась иллюзия, что пользователь текущей транзакции – 

единственный. Однако в реальности, по соображениям производительности и 

для выполнения некоторых специальных задач, СУБД предоставляют 

различные уровни изоляции транзакций. 

Уровни описаны в порядке увеличения изолированности транзакций и, 

соответственно, надёжности работы с данными [12]. 

0 – Чтение незафиксированных данных (Read Uncommitted) – 

чтение незафиксированных изменений как своей транзакции, так и 

параллельных транзакций. Нет гарантии, что данные, изменённые другими 

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

поэтому такое чтение является потенциальным источником ошибок. 

Невозможны потерянные изменения (lost changes), возможны грязное 

чтение (dirty read), неповторяемое чтение и фантомы. 

1 – Чтение зафиксированных данных (Read Committed)– чтение всех 

изменений своей транзакции и зафиксированных изменений параллельных 

транзакций. Потерянные изменения и грязное чтение не допускается, 

возможны неповторяемое чтение и фантомы.