ER-метод логического проектирования баз данных и его реализация в среде СУБД MS Access

Автор работы: Пользователь скрыл имя, 02 Июня 2012 в 01:36, курсовая работа

Краткое описание

Основные этапы проектирования базы данных
Создание базы данных (БД) в среде системы управления базами данных Access (СУБД Access) предполагает выполнение следующих основных этапов:
1. концептуальное проектирование;
2. логическое проектирование;
3. физическое проектирование;
4. использование БД – заполнение БД оперативной информацией и формирование запросов и отчетов.
Концептуальное проектирование – процедура конструирования информационной модели предприятия, не зависящей от условий реализации БД. Таким образом, сконструированная на данном этапе информационная модель не зависит ни от СУБД, ни от средств вычислительной техники.
Концептуальное проектирование БД выполняется на основе:
• анализа информационных потоков организации;
• использования классификаторов и систем кодирования;
• определения диапазона действия и области применения БД;
• выяснения состава ее пользователей;
• сбора и анализа требований пользователей.
В настоящем пособии не рассматривается методика проведения концептуального проектирования. Мы будем считать его выполненным и, таким образом, предполагается, что к моменту начала логического проектирования БД сконструирована информационная модель рассматриваемой предметной области. На этапе логического проектирования информационная модель предприятия уточняется с учетом типа создаваемой БД – реляционной, сетевой или иерархической. В настоящее время реляционные модели БД практически повсеместно вытеснили все другие типы моделей. В СУБД Access реализована именно реляционная БД.
Процесс физического проектирования БД предполагает выполнение в среде выбранной СУБД следующих работ:
1. описание логической структуры каждой таблицы;
2. описание связей между таблицами, входящими в одну БД;
3. первоначальное заполнение справочников БД необходимой нормативно-справочной информацией.
Подчеркнем, что концептуальное проектирование БД не связано с какой-либо конкретной СУБД, а этап логического проектирования зависит только от типа СУБД – сетевая, иерархическая или реляционная. Однако способ представления результатов концептуального проектирования зависит от используемого метода логического проектирования. Используемые ниже термины – отношение и атрибут – относятся к реляционной СУБД, каковой и является СУБД Access.
Поскольку одна из целей нашего курса состоит в изучении технологии применения СУБД Access для реализации реляционных баз данных, то перечисленные выше последние два этапа создания БД предполагают знание пользователем именно этой СУБД.

Вложенные файлы: 1 файл

Курсовая.doc

— 574.00 Кб (Скачать файл)


БЕЛКООПСОЮЗ

Учреждение образования

«Белорусский торгово-экономический университет потребительской

кооперации»

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

Курсовая работа

по дисциплине «Введение в системы баз данных»

на тему

«ER-метод логического проектирования баз данных и его реализация в

среде СУБД MS Access»

на примере задачи «Учет нематериальных активов (4-й вариант)»

Гомель 2011


ВВЕДЕНИЕ

              Основные этапы проектирования базы данных

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

1.      концептуальное проектирование;

2.      логическое проектирование;

3.      физическое проектирование;

4.      использование БД – заполнение БД оперативной информацией и формирование запросов и отчетов.

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

              Концептуальное проектирование БД выполняется на основе:

      анализа информационных потоков организации;

      использования классификаторов и систем кодирования;

      определения диапазона действия и области применения БД;

      выяснения состава ее пользователей;

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

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

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

1.      описание логической структуры каждой таблицы;

2.      описание связей между таблицами, входящими в одну БД;

3.      первоначальное заполнение справочников БД необходимой нормативно-справочной информацией.

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

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

 

              Концепция ER-метода логического проектирования

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

1.      выделены все сущности, информация о которых должна содержаться в искомой БД;

2.      определены основные атрибуты для каждой сущности;

3.      назначен ключевой атрибут для каждой сущности;

4.      сформулированы связи между выделенными сущностями;

5.      выявлены условия применения выделенных сущностей на данном предприятии.

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

              В качестве определения ER-метода можно принять следующее:

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

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

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

 

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

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

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

              Атрибут есть свойство сущности.

              Например, атрибутами (свойствами) сущности Студент являются: фамилия, имя, отчество, номер зачетной книжки, год рождения, академическая группа и т.д.

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

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

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

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

              Характеристики связи во многом определяются условиями применения сущностей. Условия применения – это производственные правила, установленные в данной организации, использования выделенных для БД объектов.

 

              ER-диаграммы

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

              Сущность Продукт характеризуется такими атрибутами как Номер продукта (НП), Наименование продукта (НАИМ), Единица измерения (ЕИ), Упаковка (УП) и др. Для дальнейшего рассмотрения важно лишь то, что атрибут НП является ключом сущности Продукт. Это означает, что значение атрибута НП однозначно определяет конкретный продукт, т.е экземпляр сущности Продукт. Для определенности будем считать, что НП принимает следующие значения: П1, П2, П3 и т.д.

              Сущность Склад обладает следующими атрибутами: Номер склада(НС), Емкость склада (ЕС), Материально ответственное лицо (МОЛ) и т.д. Ключом сущности является атрибут НС. Будем считать, что НС принимает значения С1, С2, С3 и т. д.

              Сущности Продукт и Склад соотносятся с помощью связи Хранится. Эта связь может быть графически представлена в виде диаграммы ER-экземпляров и диаграммы ER-типа.

                                          ПРОДУКТ                                ХРАНИТСЯ                            СКЛАД

                                                 П1                                                                                          С1

                                                 П2                                                                                          С2

                                                 П3                                                                                          С3

                                                 П4                                                                                          С3

 

Рис. 1 Пример диаграммы ER-экземпляров

 

 

 

 

 

                            НП….                                                                                                          НС….

 

Рис. 2 Пример диаграммы ER-типа

              В большинстве случаев для определения набора отношений проектируемой БД используются диаграммы ER-типа, а не диаграммы экземпляров.

 

              Характеристики связи

              Важной характеристикой связи между двумя (и более) сущностями является степень связи.

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

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

              Наиболее распространенными являются бинарные связи с показателями кардинальности "один к одному" (1:1), "один ко многим" (1:n) или "многие к одному" (n:1), "многие ко многим" (m:n).

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

              Если рассмотреть две сущности Академическая группа (ключ – шифр группы) и Факультет (ключ – шифр факультета), то показатель кардинальности связи Принадлежит между экземплярами этих сущностей равен n:1, т.е. каждая группа обязательно принадлежит какому-то одному факультету, но в каждом факультете есть несколько групп. Заметим, что между сущностями Факультет и Академическая группа показатель кардинальности связи равен 1:n.

              Для связи Преподает (Читает) между сущностями Преподаватель и Учебный курс (Дисциплина) показатель кардинальности будет m:n, т.к. каждый преподаватель читает несколько курсов и каждый курс может читаться разными преподавателями (для разных потоков).

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

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

              Чтобы различать связи такого рода используется еще одна характеристика связи - класс принадлежности сущности для (конкретной) связи.

Информация о работе ER-метод логического проектирования баз данных и его реализация в среде СУБД MS Access