POSOB981

		О г л а в л е н и е
			Стр.
	Введение . . . . . . . . . . . . . . . . . . . .	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	5
	Глава1. Проектирование баз данных . . . . . . . . . . . . . . . . . . . . . . . . . . .		7
	1.1. Этапы проектирования базы данных. . . . . . . . . . . . . . . . . . . . .		7
	1.2. Инфологическое проектирование . . . . . . . . . . . . . . . . . . . . . . .		8
	1.2.1. Сущности и атрибуты . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		8
	1.2.2. Связи . . . . . . . . . . . .	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	11
	1.2.3. Формализация связей . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		15
	1.2.4. Развитые элементы ER-модели . . . . . . . . . . . . . . . . . . . . .		19
	Вопросы для самопроверки	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	22
	Глава 2. Логическое проектирование реляционных баз данных . . . .		24
	2.1Проектирование реляционных баз данных с использовани-
	ем аппарата нормализации . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		24
	2.2. Нормальные формы . . . .	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	25
	2.3. Об ограничениях целостности . . . . . . . . . . . . . . . . . . . . . . . . . .		33
	2.4. Получение реляционной схемы из ER-модели . . . . . . . . . . . .		35
	Вопросы для самопроверки .	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	37
	Глава 3. Пример проектирования базы данных отдела снабжения
	автомобильной службы . . . . . . . .	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	39
	3.1. Предметная область . . . .	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	39
	3.2. Инфологическая модель базы данных . . . . . . . . . . . . . . . . . .		42
	3.3. Реляционная схема базы данных . . . . . . . . . . . . . . . . . . . . . .		43
	Глава 4. Задания для выполнения лабораторных, курсовых и
	исследовательских работ по теме “Проектирование и разработка баз
	данных” . . . . . . . . . . . . . . . . . . . . .	. . . . . . . . . . . . . . . . . . . . . . . . . . . .	49
	4.1. Информационная система Вуза . . . . . . . . . . . . . . . . . . . . . . . .		49
	4.2. Информационная система торговой организации . . . . . . . . .		51
	4.3. Информационная система медицинских организаций города . . . .		53
	. . . . . . . . . . . . . . . . . . . .	. . . . . . . . . . . . . . . . . . . . . .
	4.4. Информационная система автопредприятия города . . . . . .		55
	4.5. Информационная система проектной организации . . . . . . .		56
	4.6. Информационная система авиастроительного предприятия . . . . . . .		57
	. . . . . . . . . . . . . . . . . . . .	. . . . . . . . . . . . .
	4.7. Информационная система военного округа . . . . . . . . . . . . . .		59
	4.8. Информационная система строительной организации . . . .		60
	4.9. Информационная система библиотечного фонда города . . .		62
	4.10. Информационная система спортивных организаций города . . . . .		63
	4.11. Информационная. . . . . . . . . . . . . . . система. . . . . . . .автомобилестроительного. . . . . . . . . . . . . . . . . . предприятия
			64
	. . . . . . . . . . . . . . . . . . . . .	. . . . . . . . . . . . . . . . . . .
	4.12. Информационная система гостиничного комплекса . . . . . .		66

3

4.13. Информационная система магазина автозапчастей . . . . . .	67
4.14. Информационная система представительства туристи-
ческой фирмы в зарубежной стране. . . . . . . . . . . . . . . . . . . . . . .	69
4.15. Информационная система аптеки . . . . . . . . . . . . . . . . . . . . .	70
4.16. Информационная система библиотеки вуза . . . . . . . . . . . .	72
4.17. Информационная система туристического клуба . . . . . . . .	73
4.18. Информационная система городской телефонной сети . . .	75
4.19. Информационная система театра . . . . . . . . . . . . . . . . . . . . .	77
4.20. Информационная система аэропорта. . . . . . . . . . . . . . . . . . .	78
4.21. Информационная система зоопарка . . . . . . . . . . . . . . . . . . .	80
4.22. Информационная система ГИБДД . . . . . . . . . . . . . . . . . . . . .	82
4.23. Информационная система фотоцентра . . . . . . . . . . . . . . . . .	83
4.24. Информационная система железнодлрожной пассажир-
ской станции . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	85
4.25. Информационная система городской филармонии . . . . . .	87
Список литературы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	88

4

В в е д е н и е

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

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

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

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

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

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

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

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

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

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

5

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

При проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей. Сбор данных начинается с изучения сущностей предметной области, процессов, использующих эти сущности, и связей между ними [3, 5-7, 9, 11-13, 15, 17-19] и заканчивается построением ER-модели, являющейся базисом формализованной модели данных. На сегодняшний день в подавляющем большинстве случаев это реляционная модель данных [1-2, 4, 7-10, 11-13, 15-16], ставшая по сути дела стандартом де-факто для построения систем баз данных и позволяющая средствами формализованного языка манипулировать данными [7-8, 15-16, 20-21].

Основная цель проектирования базы данных – это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте [1-6, 7-9, 12-16].

Учебное пособие содержит большое число примеров, схем и диаграмм, способствующих успешному усвоению материала. Первые две части учебного пособия заканчиваются перечнем вопросов для контроля и самопроверки. Приведенные в части 4 учебного пособия варианты заданий можно рекомендовать для выполнения курсовых, лабораторных и исследовательских работ по дисциплинам “Базы данных” и ”Распределенные базы данных”. Автор выражает благодарность студентам факультета ФПМИ Бакуниной Татьяне и Закревской Наталье, участвовавших в подготовке вариантов заданий.

Глава I. Проектирование баз данных

1.1. Этапы проектирования базы данных

При проектировании базы данных решаются три основных проблемы:

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

6

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

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

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

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

Логическое

проектирование

Описание на языке

конкретной СУБД

Датологическое

проектирование

Физическое проектирование Описание хранимых данных

иметодов доступа к ним

1.2.Инфологическое проектирование

7

Одной из наиболее популярных семантических моделей данных на этапе инфологического проектирования является неформальная модель "Сущность-Связь" (Entity-Relationship - ER-модель). Модель была предложена Ченом (Chen) в 1976 г.

Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных (и не только их) ERмодели получили широкое распространение в CASE-системах (Computer Aided Software Engineering – программные средства, поддерживающие процессы автоматизированного проектирования баз данных, создания и сопровождения ПО (приложений) и баз данных, генерацию кода, тестирование, документирование и управление проектом).

Замечание. Существует большое число нотаций ER-модели, несущественно отличающихся между собой:

•нотация Баркера;

•нотация IDEF1, предложенная T.Ramey (Erwin, Design/IDEF, Silverrun);

•нотация Yourdona (Vantage Team Builder (бывший Vestmount I-CASE)).

Основными понятиями ER-модели являются сущность, связь, атрибут.

1.2.1. Сущности и атрибуты

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

Ниже изображена сущность АЭРОПОРТ (тип сущности) с примерными экземплярами сущностей Шереметьево и Толмачево:

Аэропорт (Шереметьево, Толмачево)

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

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

(<имя сущности>.<Имя атрибута>). Например,

Самолет.Размах крыла Кошка.Вес

8

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

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

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

Аэропорт: Код аэропорта	Идентификатор
Широта	Идентификатор
Долгота
Город	не могут быть
Пропускная способность	идентификаторами

Способы представления сущностей: 1. Графически

			Имя сущности (тип сущности)
Номер типа			Ключевой литерал
	5. Кошка (К)
сущности	* Имя
Привилегированный	•	Пол	Неидентифицирующий
атрибут	•	Вес	атрибут

•Цвет

•Темперамент

2.В текстовом представлении

Кошка (Имя, Пол, Вес, Цвет, Темперамент) 3. В табличном виде

		Кошка			экземпляры
Имя	Пол	Вес	Цвет	Темперамент
Мурка	ж	3,5	бурый	распутный	сущности
Васька	м	3	рыжий	ленивый

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

различных типов:

•описательные;

•указывающие;

•вспомогательные.

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

9

Счет.Сальдо Источник элекроснабжения.Полярность Кошка.Вес

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

Указывающие атрибуты используются для присвоения имени или обозначения экземпляров сущности:

Счет.Номер Груз.Номер накладной Город.Название

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

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

Кошка.Имя хозяина Счет.ID клиента

Магнит.Источник электроснабжения

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

Правила атрибутов :

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

	Владелец	Модель	Изготовитель		Нарушение первого
					правила атрибутов
	Грин	Фургон	Шевроле
					(незаполненные ячейки
	Джонс	Джип
					и ячейки с группой
	Кларк	Гузовик	Форд
					значений)
			Сузуки
	2. Атрибут не должен содержать никакой внутренней структуры
	Заводской	Модель			Нарушение второго
	номер	изготовителя
					правила атрибутов
	670978	Москвич 2141			(невозможно выделить
	879800	Москвич 412			изготовителя)
	078876	Луаз 969М

10

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

Перемещение Сока (ID Бака-хранилища, ID Бака для приготовления, Количество литров, Время приготовления)

Обозначает количество перемещаемых литров (характеристика всего объекта), а не Идентификатор

объем того или другого бака

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

Порция Сока (ID Порции, ID Рецепта, Количество литров, Время приготовления)

Обозначает фактическое время приготовления порции, а не время, предусмотренное рецептом Идентификатор

приготовления

1.2.2. Связи

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

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

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

1. Муж (М)				R1	Женат на			2. Жена (Ж)
* Имя мужа			Замужем за					* Имя жены
• Другие атрибуты								• Другие атрибуты
(Связь R1 – традиционный брак: каждый муж имеет одну жену и каждая жена имеет
одного мужа).										В нотации
		1			1					Yourdana
1. Муж (М)				Брак		2. Жена (Ж)
* Имя мужа						* Имя жены
• Другие атрибуты						•	Другие атрибуты

11

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

3. Собака (С)			Владеет		4. Владелец собаки (ВС)
* ID собаки					* ID владельца
•	Имя		R2	Принадлежит	•	Имя владельца
•	Порода				•	Адрес
•	Вес				•	Номер телефона

(Связь R2 – владение собаками: каждый владелец может иметь одну или несколько собак, но каждая собака принадлежит только одному владельцу).

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

5. Дом (Д)		Владеет		6.	Владелец дома (ВД)
* Адрес				*	Имя владельца
* Квартира		R3	Является	*	Адрес
•	Площадь			•	Номер телефона
•	Квартплата	собственностью

(Связь R3 – домовладение: каждый владелец может иметь один или несколько домов, и каждый дом является собственностью одного или несколько владельцев).

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

7.	Офис (О)	Предназна-	8. Служащий		Подчиняется	9. Подчиненный
*	Здание	У чен для	* ID служащего		R5 У	* ID подчиненного
*	Номер	R4 У	•	Имя	Курирует	•	Имя
•	Площадь	Работает в	•	Адрес		•	ID начальника
			•	Телефон

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

Суммируя вышесказанное, можно выделить 10 форм для связей, включающих две сущности.

Безусловные формы (участвует каждый экземпляр )

1:1	1:М	М:N

Условные формы (с одной стороны не все экземпляры участвуют в связи)

12