МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«Кузбасский государственный технический университет»

Кафедра вычислительной техники и информационных технологий

ПРОЕКТИРОВАНИЕ, СОЗДАНИЕ И
ИСПОЛЬЗОВАНИЕ БАЗ ДАННЫХ MS ACCESS
Часть 1. КОНЦЕПТУАЛЬНОЕ И ЛОГИЧЕСКОЕ
ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

Методические указания к лабораторной работе по

дисциплине “Информационные системы в экономике”
для студентов экономических специальностей

Составители В.В. Крюкова

В.О. Жемчужин

Утверждены на заседании кафедры

Протокол № 8 от 30.04.03
Рекомендованы к печати учебно-методической
комиссией по специальности 060800
Протокол № 12 от 21.05.03
Электронная копия хранится в библиотеке
главного корпуса ГУ КузГТУ

Кемерово 2003
 1
Цель работы: приобрести умение анализировать предметную об-
ласть (ПО) информационной системы и на основе анализа создавать
концептуальную, логическую модели будущей базы данных.

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

Основные понятия

Автоматизированная информационная система (АИС) – это ком-

плекс программных и технических средств, обеспечивающих сбор, об-
работку и манипулирование данными.
Цель любой информационной системы (ИС) – обработка данных
об объектах реального мира. Основой ИС является база данных (БД). В
широком смысле слова БД – это совокупность сведений о конкретных
объектах реального мира в какой-либо ПО. В узком смысле БД – это
поименованная, определённым образом организованная совокупность
данных, отражающая состояние объектов и их отношений в
рассматриваемой ПО.
Под ПО принято понимать часть реального мира, подлежащего
изучению для организации управления.
Объектом называют элемент ПО, информация о котором интере-
сует пользователя. Каждый объект описывается рядом основных
свойств – атрибутов. Атрибутом называют поименованную
характеристику объекта. Он показывает, какая информация об объекте
интересует пользователя и должна храниться в БД. Например, ПО –
высшее учебное заведение; объекты – студент, преподаватель; атри-
буты – фамилия студента, его адрес проживания, группа, фамилия пре-
подавателя, дисциплина, которую он читает, учёное звание и учёная
степень.
Процесс проектирования БД состоит из трёх этапов: концептуаль-
ного, логического и физического проектирования. Результат каждого
этапа – соответствующая модель ПО, что отражает трёхуровневую ар-
хитектуру (концептуальный, внешний, внутренний уровни) любой ав-
томатизированной ИС.

ЭТАП КОНЦЕПТУАЛЬНОГО ПРОЕКТИРОВАНИЯ

Концептуальное проектирование начинается с анализа ПО, вклю-
чает анализ концептуальных требований и информационных потребно-
 2
стей, выявление информационных объектов (ИО) и связей между ними,
построение концептуальной модели (схемы) данных.
Объединение частных представлений о содержимом БД, получен-
ных в результате опроса пользователей, позволяет создать обобщённое
неформальное описание создаваемой БД. Это описание, выполненное с
использованием естественного языка, математических формул, таблиц,
графиков и других средств, понятных проектировщикам ИС, называют
концептуальной (инфологической) моделью данных.
Основными конструктивными элементами инфологических моде-
лей являются сущности, связи между ними и их атрибуты (свойства).
Сущность (информационный объект) (ИО) – любой конкретный
(реальный) или абстрактный объект в рассматриваемой ПО.
Связь – наблюдаемая взаимосвязь (ассоциация) между сущно-
стями.
Для представления концептуальной модели используют различные
методы и модели, например, модель “сущность” – “атрибут” – “связь”
(EAR) описывает ПО на концептуальном уровне в виде EAR-диаграмм.
В них сущности помечаются прямоугольниками, ассоциации (харак-
теры объединения сущностей) – ромбами или шестиугольниками, атри-
буты – овалами, а связи между ними – рёбрами, над которыми простав-
ляются типы связей.
Между сущностями возможны четыре типа связей: один – к од-
ному (1 ↔ 1), один – ко многим (1 ↔ ∞), многие – к одному (∞ ↔ 1),
многие – ко многим (∞ ↔ ∞).
Связь 1 ↔ 1: в любой момент времени каждому экземпляру пер-
вого ИО соответствует 1 или 0 экземпляров другого ИО и наоборот.
Связь 1 ↔ ∞: одному экземпляру первого ИО соответствует
0,1,2,… экземпляров другого и наоборот, каждому экземпляру второго
ИО соответствует 0 или 1 экземпляр первого ИО. Аналогично опреде-
ляется тип связи ∞ ↔ 1.
Связь ∞ ↔ ∞: одному экземпляру первого ИО соответствует
0,1,2,… экземпляров другого ИО и наоборот.
Примеры:
1. Студент 1 ↔ 1 Сессия: каждый студент имеет определённый на-
бор экзаменационных оценок в сессию. Имеется в виду ИО Сессия
как набор оценок за текущий семестр.
 3
2. Стипендия 1 ↔ ∞ Студент: вид (и сумма) стипендии может
многократно повторяться для различных студентов по результатам
сессии.
3. Студент ∞ ↔ ∞ Преподаватель: один студент обучается у
многих преподавателей и наоборот, один преподаватель обучает
многих студентов.
Концептуальная модель применяется для структурирования ПО с
учётом информационных интересов пользователей ИС, она не зависит
ни от программных, ни от технических решений.
Рассмотрим пример: проектирование БД ИС “Бухгалтерский учёт
на предприятии”. Фрагмент концептуальной модели, соответствующей
подсистеме “Расчёты с контрагентами”1 в виде EAR-диаграмм “сущ-
ность” – “атрибут” – “связь”, представлен на рис. 1. В результате ана-
лиза ПО выделено четыре ИО (План счетов, Контрагенты, Валюты,
Журнал хозяйственных операций (ЖХО)), их свойства и связи.
Определим связи между сущностями:
Название связи Тип Связи между сущностями
Регистрация операции 1 ↔ ∞ Контрагенты, ЖХО
Отнесение операции на счёт 1 ↔ ∞ План счетов, ЖХО
Валютный учёт (денежное
1 ↔ ∞ Валюты, ЖХО
отражение)
Итак, концептуальная модель – это описание ПО, включающее
совокупность информационных объектов, их атрибутов и взаимосвязей,
выявленных в результате анализа.

1
Автор – Зинкевич О.А., студентка гр. Э-962 ИЭФ
 4
Наименование
операции
№ операции
Дебет
Код валюты

Кредит
Дата
операции
Сумма в
валюте

Сумма в
рублях

Код
контрагента
∞
∞ Журнал хозяйствен-
ных операций Денежное
∞ отражение
Регистрация операции
операции с
контрагентом 1
Валюты
1 Отнесение
Контрагенты операции на
счёт Код валюты

Адрес Дата
Код
контрагента
ФИО Наименование
Название валюты
контрагента 1
Расчётный
счёт План Обозначение
Номер
телефона
Филиалы Курс

Тип счёта
Фото
Номер счёта
Журнал-
ордер
Название
счёта
Ведомость

Рис. 1. Фрагмент концептуальной модели ПО

“Бухгалтерский учёт на предприятии”
 5
ЭТАП ЛОГИЧЕСКОГО ПРОЕКТИРОВАНИЯ
Основной задачей логического проектирования является разра-
ботка логической схемы (модели), ориентированной на выбранную
систему управления базами данных (СУБД).
СУБД – это комплекс программных и языковых средств, предна-
значенных для создания, ведения и совместного применения БД лю-
быми пользователями.
СУБД осуществляет централизованное управление базой данных,
обеспечивает доступ к данным, по сути, выступает в качестве
интерфейса между пользователями и БД.
Одним из основных критериев выбора СУБД является оценка
того, насколько эффективно внутренняя модель данных, поддерживае-
мая системой, способна описать концептуальную схему ПО. Сущест-
вующие СУБД делятся по типам моделей данных на реляционные, ие-
рархические и сетевые.
Модель данных (МД) – формально определённая структура, кото-
рая используется для представления данных. Иерархическая МД орга-
низует данные в виде древовидной структуры, сетевая – в виде сетевой,
реляционная МД – в виде таблиц (отношений).
Процесс логического проектирования состоит из следующих дей-
ствий:
− выбор конкретной СУБД;
− отображение концептуальной схемы на логическую схему,
получение логической МД, соответствующей внешнему
уровню архитектуры любой автоматизированной ИС;
− выбор ключей;
− описание языка запросов.
При отображении концептуальной МД ПО на реляционную МД
каждый прямоугольник схемы (рис. 1) – информационный объект
преобразуется в таблицу (отношение).
Теория конструирования реляционных БД разработана доктором
Е.Ф. Коддом в 1968 г. Сформулированные им 13 правил [2] полностью
реализованы в реляционной СУБД MS Access. Им же введены основ-
ные понятия реляционной БД, которыми являются: “тип данных”, “до-
мен”, “атрибут”, “кортеж”, “первичный ключ”, “отношение”.
Понятие “тип данных” в реляционной МД полностью адекватно
понятию типа данных в языках программирования.
 6
Рассмотрим отношение “План счетов” (рис. 2).

первичный
ключ д о м е н ы

Номер Тип Журнал- атрибуты

План счетов
Отношение

Название счёта Ведомость

счёта счёта ордер
50 Касса А 1 1
51 Расчётный счёт А 2 2 кортежи
52 Валютный счёт А 3 3

Рис. 2. Отношение “План счетов”

Домен определяется как допустимое потенциальное множество

значений данного (стандартного) типа. Например, для домена “назва-
ние счёта” допустимость означает, что множество значений – только те,
которые представлены в плане счетов – документе как названия счетов.
Схема отношения – это именованное множество пар {имя атри-
бута, имя домена}. Степень или “арность” схемы отношения – мощ-
ность этого множества. Степень отношения “План счетов” равна 5.
Кортеж, соответствующий данной схеме отношения, – это
множество пар {имя атрибута, значение}, которое содержит одно вхож-
дение каждого имени атрибута, принадлежащего схеме отношения, а
“значение” – допустимое значение домена данного атрибута.
Отношение – это множество кортежей, соответствующих одной
схеме.
В литературе часто используют неформальную терминологию ре-
ляционных баз данных: отношение – таблица, кортеж – строка, домен –
столбец.
Доктор Е.Ф. Кодд ввёл понятия реляционной алгебры (РА) и
реляционного исчисления (РИ) [2].
РА – совокупность множества отношений и множества операций
над ними. С точки зрения обработки информации РА является проце-
дурным языком обработки реляционных таблиц, обеспечивающим по-
шаговое решение задач. РИ – непроцедурный язык, позволяющий фор-
мулировать, что нужно сделать, а не как. Например, в РИ запрос созда-
ётся путём определения таблицы (бланка) запроса за один шаг.
Е.Ф. Кодд показал, что понятия РА и РИ логически эквивалентны, что
чрезвычайно важно. Это означает, что любой запрос, который можно
 7
сформулировать при помощи РИ, также можно сформулировать, поль-
зуясь РА, и наоборот.

ФУНДАМЕНТАЛЬНЫЕ (БАЗОВЫЕ) СВОЙСТВА

ОТНОШЕНИЙ
Отсутствие кортежей-дубликатов. Из этого свойства вытекает
наличие у каждого отношения первичного ключа (ПК) – набора атрибу-
тов, значения которых однозначно определяют кортеж отношения. По-
нятие ПК является исключительно важным в контексте с понятием
целостности БД.
Целостность базы данных – свойство, определяемое способно-
стью СУБД защищать компоненты и связи БД от искажений в резуль-
тате некорректных операций или сбоев и отказов технических средств.
Отсутствие упорядоченности кортежей. Отсутствие требования
к поддержанию порядка на множестве кортежей отношения даёт допол-
нительную гибкость СУБД при хранении БД во внешней памяти и при
выполнении запросов к ней.
Атомарность значений атрибутов. Значения всех атрибутов
являются атомарными. Это следует из определения домена как потен-
циального множества значений одного простого типа данных, т.е. среди
значений домена не могут содержаться множества (т.е. одна ячейка
таблицы – одно значение).
Реляционная модель данных (РМД) – совокупность связанных таб-
лиц. Реляционную модель можно условно разделить на три части, опи-
сывающие разные аспекты реляционного подхода: структурную, мани-
пуляционную и целостную.
В структурной части модели фиксируется, что единственной
структурой данных, используемой в реляционных БД, является норма-
лизованное N-арное отношение (таблица).
В манипуляционной части модели утверждаются два фундамен-
тальных механизма манипулирования реляционной БД – реляционная
алгебра и реляционное исчисление. Основной функцией манипуляци-
онной части реляционной модели является обеспечение меры реляци-
онности любого конкретного языка БД.
В целостной части РМД фиксируются два базовых требования це-
лостности, которые должны поддерживаться в любой реляционной
СУБД: целостность сущностей и целостность по ссылкам.
 8
Требование целостности сущностей означает, что любой кортеж
любого отношения отличим от любого другого кортежа этого отноше-
ния, другими словами, любое отношение должно иметь первичный
ключ. Это требование автоматически удовлетворяется, если в системе
не нарушаются базовые свойства отношений.
Требование целостности по ссылкам иначе называют
требованием внешнего ключа.
Напомним, первичный ключ отношения (таблицы) – один или не-
сколько атрибутов (полей), значения которых однозначно определяют
кортеж (запись) таблицы. Связь между отношениями (таблицами)
осуществляется путём включения общих полей. Поле первичного ключа
одной (говорят, главной) таблицы присутствует в качестве обычного
поля в связанной (подчинённой) таблице, его и называют внешним
ключом по отношению к главной таблице, например, поле Код
контрагента в таблице Контрагенты – первичный ключ, такое же поле
Код контрагента в таблице Журнал хозяйственных операций –
внешний ключ (рис. 3). Требование целостности по ссылкам означает,
что для каждого значения внешнего ключа подчиненного отношения
должен быть кортеж с таким же значением первичного ключа главного
отношения, либо значение внешнего ключа должно быть
неопределённым (ни на что не указывать). Ограничения целостности
должны поддерживаться СУБД.
Для соблюдения целостности сущностей достаточно гарантиро-
вать отсутствие в любом отношении кортежей с одним и тем же значе-
нием первичного ключа.
В обеспечении целостности по ссылкам существуют три подхода.
Первый подход заключается в том, что запрещается производить
удаление кортежа, на который существуют ссылки, т.е. сначала нужно
либо удалить ссылающиеся кортежи, либо изменить значения из внеш-
него ключа должным образом.
При втором подходе при удалении кортежа, на который имеются
ссылки, во всех ссылающихся кортежах значение внешнего ключа ав-
томатически становится неопределённым.
Третий подход (каскадное удаление) состоит в том, что при удале-
нии кортежа из отношения, на которое есть ссылка, автоматически уда-
ляются все ссылающиеся кортежи.
 9
В современных СУБД (в том числе MS Access) обычно можно вы-
брать способ поддержания целостности по ссылкам для каждой отдель-
ной ситуации (связи) определения внешнего ключа.

НОРМАЛИЗАЦИЯ БД
При проектировании реляционных БД большое внимание уделя-
ется нормализации таблиц. В процессе нормализации обеспечивается
защита целостности данных путём устранения их дублирования. В ре-
зультате исходная таблица разбивается на две или более связанных таб-
лиц, которые могут быть “собраны” вместе с помощью операции объе-
динения. Руководство по нормализации – это набор стандартов (пра-
вил) проектирования данных, называемых нормальными формами
(НФ).
Общепринятыми считаются пять нормальных форм, хотя их было
предложено больше. Создание таблиц в соответствии с этими стандар-
тами называется нормализацией.
Нормальные формы изменяются в порядке от первой до пятой.
Каждая последующая форма удовлетворяет требованиям предыдущей.
Кратко сформулируем стандарты нормализации.
Реляционная таблица (РТ) находится в первой НФ, если значения в
ней являются атомарными для каждого атрибута.
Вторая НФ требует, чтобы любой неключевой столбец зависел от
всего первичного ключа.
Третья НФ требует, чтобы ни один неключевой столбец не зави-
сел от другого неключевого столбца. Любой неключевой столбец дол-
жен зависеть только от первичного ключа.
Четвёртая НФ запрещает независимые отношения типа один – ко
многим между ключевыми и неключевыми столбцами.
Нормальные формы более высоких порядков рассматривать не бу-
дем, т.к. они являются лишь желательными, но не обязательными.
Большинство разработчиков баз данных признают, что представ-
ление данных в третьей и четвёртой НФ полностью удовлетворяет все
их потребности.
Отобразим концептуальную модель ПО на логическую схему, ори-
ентируясь на СУБД MS Access, получим фрагмент логической модели
БД “Бухгалтерский учёт на предприятии”2 (рис. 3).

2
Автор – Зинкевич О.А., студентка гр. Э-962 ИЭФ
 10

ЖХО Валюты
№ операции
1 Код валюты
∞
Код валюты Дата
Дата 1 Наименование
∞
Операция Обозначение
Дебет Курс
Кредит ∞
Сумма в валюте
Сумма в рублях
Код контрагента
∞ План счетов
Номер счёта
1 Название
Контрагент
Код контрагента Тип
Название 1 Журнал-ордер
Телефон Ведомость
Адрес
ФИО
Расчётный счёт
Фото
Рис. 3. Логическая модель БД

Все таблицы имеют четвёртую НФ. В таблице ЖХО простой пер-

вичный ключ – поле Номер операции. Простой ключ состоит из одного
поля, составной – из нескольких полей. В таблице Валюты первичный
ключ составной – из двух полей Код валюты и Дата. В таблице План
счетов первичный ключ – поле Номер счёта. В таблице Контрагенты
первичный ключ – поле Код контрагента. В таблице ЖХО поля Код
валюты, Дата, Дебет, Код контрагента – внешние ключи, тип связей
∞ ↔ 1.
Следующий этап – физическое проектирование: логическая
модель данных отображается на физическую схему, в результате
получается физическая модель, определяющая размещение данных,
методы доступа и технику индексирования. Физическая модель
соответствует внутреннему уровню архитектуры любой АИС. В
современных СУБД (в том числе MS Access) процесс физического
проектирования БД осуществляется автоматизированно средствами
самой СУБД.
Резюмируя сказанное, можно предложить следующий порядок
проектирования реляционных баз данных:
 11
1) анализ ПО, выявление информационных потребностей
пользователей (запросы, отчёты и т.д.);
2) выбор информационных объектов, их свойств, определение свя-
зей между ними;
3) представление концептуальной модели ПО в виде EAR-диа-
грамм;
4) выбор конкретной СУБД для реализации БД, например, MS Ac-
cess;
5) отображение концептуальной модели на логическую: каждый
прямоугольник EAR-диаграммы – реляционная таблица;
6) определение ключей каждой таблицы (первичных и внешних),
уточнение связей между таблицами;
7) созданную “вчерне” структуру БД (совокупность взаимосвязан-
ных таблиц) следует проанализировать на предмет соответст-
вия правилам нормализации, при необходимости внести изме-
нения (в СУБД MS Access этой цели служит инструмент Ана-
лизатор таблиц);
8) теперь Вы готовы к непосредственному созданию БД в конкрет-
ной СУБД, т.е. к этапу физического проектирования;
9) затем следует оценить свою разработку с точки зрения того,
удовлетворяют ли Вас и Ваших пользователей полученные ре-
зультаты, если нет – вернуться к пункту 1.

ЛАБОРАТОРНАЯ РАБОТА № 1
Проектирование БД
Задание:
1. Спроектировать базу данных, состоящую из четырёх–пяти
таблиц, описывающих определённую предметную область ИС.
Каждая запись таблицы должна состоять не менее чем из пяти–
восьми разнотипных полей.
2. Определить ключи таблиц и типы связей между ними.
3. Концептуальную модель ПО представить в виде EAR-диаграмм
(по аналогии с рис. 1), логическую модель – в виде схемы
сообразно рис. 3.
 12
СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ
1. Новиков Ф.А. Microsoft Office 2000 в целом / Ф.А. Новиков,
А.Д. Яценко. – СПб.: БХВ – Петербург, 2001. – 728 с.
2. Программирование в среде Access 2000: Энциклопедия
пользователя; Пер. с англ. / Стивен Форт, Том Хоун, Джеймс
Релстон. – Киев: ДиаСофт, 2000. – 544 с.
3. Дубнов П.Ю. Access 2000. Проектирование баз данных. – М.:
ДМК, 2000. – 272 с.
4. Послед Б.С. Access 2000. Базы данных и приложения. – Киев:
ДиаСофт, 2000. – 512 с.
5. Бекаревич Ю.Б. Самоучитель Microsoft Access 2000 /
Ю.Б. Бекаревич, Н.В. Пушкина. – СПб.: БХВ-Санкт-Петербург,
1999. – 480 с.
 Составители

Валентина Валентиновна Крюкова

Владислав Олегович Жемчужин

ПРОЕКТИРОВАНИЕ, СОЗДАНИЕ И
ИСПОЛЬЗОВАНИЕ БАЗ ДАННЫХ MS ACCESS
Часть 1. КОНЦЕПТУАЛЬНОЕ И ЛОГИЧЕСКОЕ
ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

Методические указания к лабораторной работе по дисциплине

“Информационные системы в экономике” для студентов
экономических специальностей

Редактор А.В. Дюмина

Подписано в печать 02.06.03

Формат 60×84/16. Бумага офсетная. Отпечатано на ризографе.
Уч.-изд. л. 0,8. Тираж 100 экз. Заказ

ГУ КузГТУ. 650026, Кемерово, ул. Весенняя, 28.

Типография ГУ КузГТУ. 650099, Кемерово, ул. Д. Бедного, 4а.