Проектирование, создание и использование баз данных MS Access. Часть 1. Концептуальное и логическое проектирование базы данных: Методические указания к лабораторной работе

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «Кузбасский государственный технический университет» Кафедра вычислительной техники и информационных технологий

ПРОЕКТИРОВАНИЕ, СОЗДАНИЕ И ИСПОЛЬЗОВАНИЕ БАЗ ДАННЫХ 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 Access; 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а.