Практический подход к проектированию баз данных

М.В. Махмутова

ПРАКТИЧЕСКИЙ ПОДХОД  
К ПРОЕКТИРОВАНИЮ БАЗ ДАННЫХ 

Учебное пособие

Москва 
Издательство «ФЛИНТА» 
2023

2-е издание, стереотипное

УДК 681.1 
ББК  32.97 
         М36 

Рецензенты: 
канд. техн. наук, зам. директора по развитию 
ЗАО «Консом СКС» Ю.Н. Волщуков 

канд. техн. наук, доцент кафедры бизнес-информатики и 
информационных технологий МГТУ им. Г.И. Носова С.А. Повитухин 

М36 

Учебное пособие «Практический подход к проектированию баз данных» 
разработано в поддержку ряда дисциплин базовой части профессионального 
цикла, таких как «Базы данных», «Технологии баз данных и СУБД», «Базы 
данных и СУБД», «Проектирование ИС», «Управление жизненным циклом 
ИС», «Разработка приложений» и др. для формирования компетенций 
выпускника по направлениям подготовки 09.03.03 «Прикладная информатика», 
38.03.05 
«Бизнес-информатика», 
44.03.05 
«Педагогическое 
образование 
(профиль информатика и экономика)», как ИТ-специалиста в области 
разработки баз данных и информационных систем.  
В учебном пособии рассмотрены основные вопросы и понятия 
технологии проектирования баз данных. Рассмотрены этапы процесса 
проектирования базы данных, проблемы автоматизации проектирования базы 
данных. Представлены некоторые аспекты создания многомерной модели. 
Изложены основы использования технологий WWW для доступа к базам 
данных.   
Предложенный теоретический материал сопровождается большим 
количеством примеров, предлагаются вопросы для самопроверки, практические 
задания и примеры их выполнения, тестовые вопросы.  
Учебное пособие ориентировано на студентов очного и заочного 
отделений, изучающих технологии баз данных, методологии моделирования 
данных, проблемы проектирования базы данных, проблемы стандартизации в 
области технологий баз данных. 

УДК 681.1 
ББК 32.97 

ISBN 978-5-9765-3694-4 
 Махмутова М.В., 2017
 Издательство «Флинта», 2017

Махмутова М.В.
    Практический подход к проектированию баз данных : учебное 
пособие / М.В. Махмутова. — 2-е изд., стер. — Москва : ФЛИНТА, 2023. 
— 159 с. — ISBN 978-5-9765-3694-4. — Текст : электронный.

ОГЛАВЛЕНИЕ

Оглавление .........................................................................................................................3
Введение...............................................................................................................................4
1. Теория проектирования базы данных............................................................................6
1.1 Основные понятия.........................................................................................................6
1.2 Концептуальное проектирование базы данных..........................................................8
1.3 Логическое проектирование базы данных ................................................................11
1.4 Физическое проектирование базы данных................................................................13
2. Классический подход к проектированию базы данных.............................................14
2.1Нормализация отношений...........................................................................................14
2.2Нормальные формы ER-схем......................................................................................15
2.3Получение реляционной схемы из ER-схемы ...........................................................16
3. Структурный подход к разработке базы данных .......................................................19
3.1Анализ предметной области........................................................................................19
3.2Реляционные основы проектирования.......................................................................22
3.3Создание логической модели базы данных...............................................................25
3.4Создание физической модели базы данных ..............................................................28
3.5Реализация базы данных..............................................................................................30
3.6Создание метаданных базы данных ...........................................................................33
4.Средства автоматизации на этапах разработки базы данных ....................................40
4.1Автоматизация проектирования базы данных ..........................................................40
4.2Наиболее популярные CASE - средства проектирования данных ..........................41
5.Методы хранения и доступа к данным.........................................................................47
5.1Методы доступа внутренней модели (физической)..................................................48
5.2Методы доступа внешней модели (представления пользователя)..........................50
6.Размерное моделирование хранилищ данных с помощью PLATINUM ERwin.......52
6.1 Основные возможности CASE-средства фирмы PLATINUM ................................52
6.2 Стандарт модели в размерном моделировании........................................................53
6.3 Описание свойств, задаваемых разработчиком........................................................55
6.4 Пример представления метаданных для хранилища данных..................................... 58
7.Использование технологий WWW для доступа к базам данных...............................65
7.1Технология World Wide Web.......................................................................................65
7.2Сценарии WWW - доступа к существующим базам данных...................................66
8. Обзор технологий..........................................................................................................70
8.1Технологии WWW .......................................................................................................70
8.2Оценка трудоемкости обеспечения WWW доступа .................................................71
8.3Информационные системы на основе Internet/Intranet-технологии ........................72
8.4Подготовка гипертекстовых документов для World Wide Web ..............................73
8.5Назначение WWW - сервера. Общая схема работы. Определение .........................74
8.6WWW и средства интерактивного взаимодействия .................................................76
8.7Интерфейс CGI .............................................................................................................77
9.Практические задания....................................................................................................80
Вопросы для самопроверки ..............................................................................................95
Тест .....................................................................................................................................97
Список использованных источников............................................................................ 101
Приложения..................................................................................................................... 108

ВВЕДЕНИЕ

В 
учебном 
пособии 
рассмотрены 
основные 
понятия 
технологии 

проектирования баз данных. Представлены основные практические подходы,
средства автоматизации процесса проектирования.
Рассмотрены этапы 

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

Базы данных являются неотъемлемой частью нашей повседневной 

жизни. Можно рассматривать базу данных как некий набор связанных данных, 
а систему управления базами данных, или СУБД (Database Management System
— DBMS), как программное обеспечение, которое управляет доступом к 
этой базе данных.

По мере развития информационных технологий совершенствовались 

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

Наряду с разработкой научных основ сформировалась и получила 

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

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

Работа ориентирована на студентов очного и заочного отделения, 

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

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

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

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

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

моделирования, представлены вниманию стандарты моделей «звезда» и 
«снежинка», возможности поддержки построения многомерной модели со 
стороны средств автоматизации.

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

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

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

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

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

1. ТЕОРИЯ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

1.1 Основные понятия
Проектирование БД – одна из наиболее сложных и ответственных задач, 

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

Главной задачей проектирования базы данных является определение 

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

1. Концептуальное проектирование.
2. Логическое проектирование.
3. Физическое проектирование.
4. Опытная эксплуатация.
Современные CASE-системы позволяют сократить число этапов при 

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

Основная цель процесса проектирования БД состоит в получении такого 

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

1.
Корректность схемы БД, т.е. база должна быть гомоморфным 

образом моделируемой предметной области (далее – ПО), где каждому объекту 
ПО соответствуют данные в памяти ЭВМ, а каждому процессу – адекватные 
процедуры обработки данных.

2.
Обеспечение ограничений (на объёмы внешней и оперативной 

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

3.
Эффективность функционирования (соблюдение ограничений на 

время реакции системы на запрос и обновление данных).

4.
Защита данных (от сбоев и несанкционированного доступа).

5.
Простота и удобство эксплуатации.

6.
Гибкость, т.е. возможность развития и адаптации к изменениям ПО 

и/или требований пользователей.

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

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

концептуальную модель данных во многих источниках называют
еще 

инфологической моделью предметной области.

Концептуальное проектирование состоит из следующих этапов:
1. Идентификация сущностей (выделение объектов рассматриваемой 

предметной области).

2. Установление всех (структурных, иерархических, запросных) связей 

между сущностями.

3. Определение атрибутов сущностей (существенных свойств объектов).
4. Нормализация модели.
5. Минимизация числа сущностей.
Этап логического проектирования предназначен для создания на основе 

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

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

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

соответствующей этому выбору СУБД - ориентированной схемы базы данных 
производится 
этап 
логического 
(его 
еще 
называют 
даталогическим) 

проектирования. Как уже говорилось ранее, современные инструментальные 
средства СУБД позволяют реализовать не только логическую модель данных, 
но и создать физическую модель, то есть совместить два этапа – этап 
логического и физического проектирования.

Основной задачей этапа логического проектирования является выбор 

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

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

должен иметь следующие данные:

1. Концептуальную модель предметной области (СУБД-независимую 

схему).

2. Характеристики одной или нескольких СУБД.
3. Вычислительные средства – ограничения на конфигурацию и объем 

аппаратного и программного обеспечения.

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

обслуживающего персонала.

Процесс логического проектирования состоит из следующих шагов после 

выбора инструментального средства:

1.
Определение локальных информационных структур. Вначале 

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

2.
Формирование первоначального варианта СУБД - ориентированной 

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

3.
Оценка характеристик полученной СУБД-схемы. Построенная на 

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

эффективность функционирования БД.

Следующий этап предназначен для создания физической модели БД, 

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

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

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

1.2 Концептуальное проектирование базы данных
Концептуальный 
подход 
не 
предоставляет 
формальных 
способов 

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

разработчиком логической базы данных – специалистом в данной предметной 
области. 

Концептуальная модель предметной области (ПО) представляет собой 

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

• используемых методов анализа предметной области; 

• правил именования и обозначения объектов ПО, атрибутов и связей; 

• содержания и формата создаваемых ими документов. 
Существуют разные подходы к концептуальному проектированию:
1. Функциональный подход к проектированию БД - этот метод является 

наиболее распространённым; он реализует принцип "от задач" и применяется в 
том случае, когда известны функции некоторой группы лиц и/или комплекса 
задач, для обслуживания информационных потребностей которых создаётся 
рассматриваемая БД;

2. Предметный подход к проектированию БД - этот метод применяется в 

тех случаях, когда у разработчиков есть чёткое представление о самой ПО и о 
том, какую именно информацию они хотели бы хранить в БД, а структура 
запросов не определена или определена не полностью; тогда основное 
внимание 
уделяется 
исследованию 
ПО 
и 
наиболее 
адекватному 
её 

отображению в БД с учётом самого широкого спектра информационных 
запросов к ней;

3. Проектирование с использованием метода "сущность–связь"- этот метод 

(Entity–Relation, ER–method) был разработан в 1976 г. П.Ченом (Chen P.P.), он 
является комбинацией двух предыдущих и обладает достоинствами обоих.

Последний 
подход 
рассмотрим 
подробнее. 
Этап 
концептуального 

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

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

Сущности, существование которых не зависит от существования других 

сущностей, называются базовыми, остальные сущности –
зависимыми. 

Например, сущность ЛЕКЦИЯ зависит от базовых сущностей ГРУППА,
ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА.

Для каждой сущности определяются атрибуты, которые делятся на два 

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

Далее осуществляется спецификация связей: выявляются связи между 

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

• объединение в единое целое фрагментарных представлений о различных 

свойствах одного и того же объекта; 

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

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

• образование классов и подклассов подобных объектов (например, класс 

"изделие" и подклассы типов изделий, производимых на предприятии). 

При небольшом количестве локальных областей (не более пяти) 

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

1.
Идентичность. Два или более элементов модели идентичны, если 

они имеют одинаковое семантическое значение.

2.
Агрегация. Позволяет рассматривать связь между элементами как 

новый элемент. Например, связь экзамен между сущностями СТУДЕНТ, 
ДИСЦИПЛИНА, 
ПРЕПОДАВАТЕЛЬ
может 
быть 
представлена 

агрегированной сущностью ЭКЗАМЕН с атрибутами Название дисциплины, 
Фамилия преподавателя, Фамилия студента, Оценка.

3.
Обобщение. Позволяет образовывать многоуровневую иерархию 

обобщений. Например, в объединяемых представлениях присутствуют 
следующие сущности:

ДЕТАЛИ СОБСТВЕННОГО ПРОИЗВОДСТВА
ДЕТАЛИ ПОКУПНЫЕ
СБОРОЧНЫЕ ЕДИНИЦЫ ПОКУПНЫЕ

СБОРОЧНЫЕ ЕДИНИЦЫ СОБСТВЕННОГО ПРОИЗВОДСТВА
Их можно объединить так, как показано на рис. 1. 

Рис.1. Использование обобщений при объединении

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

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

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

На этапе анализа ПО также решаются следующие задачи:
1.
Определение правил (ограничений целостности), которым 

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

2.
Выделение групп пользователей системы. Каждая группа 

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

3.
Создание внешней спецификации тех функций (процессов), 

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

1.3 Логическое проектирование базы данных
Определение требований к операционной обстановке. На этом этапе 

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

Выбор зависит от следующих показателей: