Файл: В.В. Крюкова Проектирование, создание и использование баз данных MS ACCESS Часть 1. Концептуальное и логическое проектирование базы данных.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 31.05.2024
Просмотров: 14
Скачиваний: 0
МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ
Государственное образовательное учреждение высшего профессионального образования
«КУЗБАССКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»
Кафедра вычислительной техники и информационных технологий
ПРОЕКТИРОВАНИЕ, СОЗДАНИЕ И ИСПОЛЬЗОВАНИЕ БАЗ ДАННЫХ 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 |
Касса |
А |
51Расчётный счёт А
52Валютный счёт А
Журнал- |
Ведомость |
|
|
|
атрибуты |
|
|
|
|||
ордер |
|
|
|
|
|
1 |
1 |
|
|
|
кортежи |
|
|
|
|||
2 |
2 |
|
|
|
|
|
|
|
|||
3 |
3 |
|
|
|
|
|
|
|
|
Рис. 2. Отношение “План счетов”
Домен определяется как допустимое потенциальное множество значений данного (стандартного) типа. Например, для домена “название счёта” допустимость означает, что множество значений – только те, которые представлены в плане счетов – документе как названия счетов.
Схема отношения – это именованное множество пар {имя атрибута, имя домена}. Степень или “арность” схемы отношения – мощность этого множества. Степень отношения “План счетов” равна 5.
Кортеж, соответствующий данной схеме отношения, – это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения, а “значение” – допустимое значение домена данного атрибута.
Отношение – это множество кортежей, соответствующих одной схеме.
В литературе часто используют неформальную терминологию реляционных баз данных: отношение – таблица, кортеж – строка, домен – столбец.
Доктор Е.Ф. Кодд ввёл понятия реляционной алгебры (РА) и
реляционного исчисления (РИ) [2].
РА – совокупность множества отношений и множества операций над ними. С точки зрения обработки информации РА является процедурным языком обработки реляционных таблиц, обеспечивающим пошаговое решение задач. РИ – непроцедурный язык, позволяющий формулировать, что нужно сделать, а не как. Например, в РИ запрос создаётся путём определения таблицы (бланка) запроса за один шаг. Е.Ф. Кодд показал, что понятия РА и РИ логически эквивалентны, что чрезвычайно важно. Это означает, что любой запрос, который можно
7
сформулировать при помощи РИ, также можно сформулировать, пользуясь РА, и наоборот.
ФУНДАМЕНТАЛЬНЫЕ (БАЗОВЫЕ) СВОЙСТВА ОТНОШЕНИЙ
Отсутствие кортежей-дубликатов. Из этого свойства вытекает наличие у каждого отношения первичного ключа (ПК) – набора атрибутов, значения которых однозначно определяют кортеж отношения. Понятие ПК является исключительно важным в контексте с понятием
целостности БД.
Целостность базы данных – свойство, определяемое способностью СУБД защищать компоненты и связи БД от искажений в результате некорректных операций или сбоев и отказов технических средств.
Отсутствие упорядоченности кортежей. Отсутствие требования к поддержанию порядка на множестве кортежей отношения даёт дополнительную гибкость СУБД при хранении БД во внешней памяти и при выполнении запросов к ней.
Атомарность значений атрибутов. Значения всех атрибутов являются атомарными. Это следует из определения домена как потенциального множества значений одного простого типа данных, т.е. среди значений домена не могут содержаться множества (т.е. одна ячейка таблицы – одно значение).
Реляционная модель данных (РМД) – совокупность связанных таблиц. Реляционную модель можно условно разделить на три части, описывающие разные аспекты реляционного подхода: структурную, мани-
пуляционную и целостную.
Вструктурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное N-арное отношение (таблица).
Вманипуляционной части модели утверждаются два фундаментальных механизма манипулирования реляционной БД – реляционная алгебра и реляционное исчисление. Основной функцией манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка БД.
Вцелостной части РМД фиксируются два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД: целостность сущностей и целостность по ссылкам.
8
Требование целостности сущностей означает, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, другими словами, любое отношение должно иметь первичный ключ. Это требование автоматически удовлетворяется, если в системе не нарушаются базовые свойства отношений.
Требование целостности по ссылкам иначе называют требованием внешнего ключа.
Напомним, первичный ключ отношения (таблицы) – один или несколько атрибутов (полей), значения которых однозначно определяют кортеж (запись) таблицы. Связь между отношениями (таблицами) осуществляется путём включения общих полей. Поле первичного ключа одной (говорят, главной) таблицы присутствует в качестве обычного поля в связанной (подчинённой) таблице, его и называют внешним ключом по отношению к главной таблице, например, поле Код контрагента в таблице Контрагенты – первичный ключ, такое же поле Код контрагента в таблице Журнал хозяйственных операций – внешний ключ (рис. 3). Требование целостности по ссылкам означает,
что для каждого значения внешнего ключа подчиненного отношения должен быть кортеж с таким же значением первичного ключа главного отношения, либо значение внешнего ключа должно быть неопределённым (ни на что не указывать). Ограничения целостности должны поддерживаться СУБД.
Для соблюдения целостности сущностей достаточно гарантировать отсутствие в любом отношении кортежей с одним и тем же значением первичного ключа.
В обеспечении целостности по ссылкам существуют три подхода. Первый подход заключается в том, что запрещается производить удаление кортежа, на который существуют ссылки, т.е. сначала нужно либо удалить ссылающиеся кортежи, либо изменить значения из внеш-
него ключа должным образом.
При втором подходе при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа автоматически становится неопределённым.
Третий подход (каскадное удаление) состоит в том, что при удалении кортежа из отношения, на которое есть ссылка, автоматически удаляются все ссылающиеся кортежи.