Устранение связи «многие-ко-многим»
Кроме нормализации отношений, при построении информационно-логической модели необходимо устранить связи типа «многие-ко-многим», так как эти связи в компьютерных базах данных напрямую не устанавливаются.
На рис. 3.1.10 между таблицами «Преподаватель» и «Дисциплина» имеется связь типа «многие – ко — многим» — один преподаватель ведет много дисциплин, одну дисциплину ведут многие преподаватели.
Рис. 3.1.10. Устранение связи «многие-ко-многим»
Устранение таких связей выполняется по следующим правилам:
ÿ создается новая (так называемая вспомогательная) таблица;
ÿ между исходными и новой таблицами устанавливаются связи типа 1:М;
ÿ из модели удаляется связь М:М.
Имя вспомогательной таблицы часто образуется как сочетание имен исходных таблиц, между которыми была обнаружена связь М:М. В общем случае вспомогательные таблицы могут не иметь собственных атрибутов; если это так, то определенные для них связи становятся ключевыми.
Информационно-логическая модель базы данных «Занятость»
Источник
Устранение связей «многие-ко-многим»
В модели Склад присутствует связь «многие-ко-многим» между сущностями Полка и Товар. Устранение этой связи требует создания межсекционной сущности. По смыслу, имя такой межсекционной сущности может быть Партия_товара. Так как в модели уже присутствует сущность Партия_товара, то в целях устранения избыточности хранения данных, эта сущность может быть использована в качестве межсекционной при устранении связи «многие-ко-многим». Результат устранения множественной связи показан на рис. 3.
Рис.3. Модель «Склад» после устранения связей «многие-ко-многим
Разработка информационной системы
Разработка физической модели базы данных
На основе модели «сущность-связь» разрабатывается структура базы данных. Физическая модель для предметной области Склад представлена на рис.4.
Рис.4. Физическая модель Склад.
На основе модели «сущность-связь» синтезируется структура базы данных. В соответствии с правилами генерации физической структуры базы данных для ER-модели Склад были получены следующие таблицы :
Обоснование выбора СУБД для реализации базы данных
· СУБД Microsoft Access — наиболее распространенная программа для создания информационных систем, на мой взгляд, из-за того, что пакет Microsoft Office есть практически в каждом доме и в каждом офисе.
· Access обладает рядом уникальных возможностей:
· · объединение информации из самых разных источников (электронных таблиц, текстовых файлов, других баз данных);
· · представление данных в удобном для пользователя виде с помощью таблиц, диаграмм, отчетов;
· · интеграция с компонентами Microsoft Office.
· Но, по моему мнению, эта программа имеет недоработки, возникают трудности при работе с этой программой.
Реализация базы данных средствами выбранной СУБД
Средствами выбранной СУБД Access созданы таблицы реляционной базы данных и схема отношений (рис.5).
Рис.5. Схема данных для базы данных «Склад»
· Реализация таблиц для базы данных Склад в Access имела следующую особенность:
· Поскольку таблица Форма_оплаты содержит только два взаимоисключающих значения: наличный или безналичный расчет, то эти значения можно закодировать числами 0 и 1, и хранить в поле таблицы Заказ. А реализацию этого поля в форме Заказ (этот объект позволяет заполнять таблицу) выполнить с помощью элемента управления «переключатель». Таким образом, из модели на рис.5 устранена таблица Форма_оплаты.
· Для ввода данных в поля Телефон в таблицах Покупатель и Поставщик применен механизм маски. Реализация этого механизма показана на рис.6.
Рис.6. Использование маски ввода для поля Тел поставщика таблицы Поставщик
Создание интерфейса пользователя для автоматизированных рабочих мест
На этапе анализа были сформулированы задачи, которые пользователи
системы будут выполнять с использованием созданной базы данных. Перечислим задачи пользователей, для решения которых необходимо разработать пользовательский интерфейс автоматизированных рабочих мест (АРМ):
1. Прием партий товара от поставщика, запас товара, данные о товарах – АРМ Товар.
2. Данные о поставщиках – АРМ Поставщик.
3. Информация и отчёты о покупателях – АРМ Покупатель.
4. Заказы товаров, отчёты о заказах – АРМ Заказ.
Меню открывается автоматически при запуске базы данных (рис.7)
Рис.7. Меню пользователя
АРМ Товары
Объекты, составляющие АРМ Товары, инициируются с помощью командных кнопок вкладки Товары из меню пользователя (рис.8).
Рис.8. Меню пользователя: вкладка Товары
Для решения задачи приема партий товаров от поставщика и размещение их на полках склада была разработана форма Партия товара, которая открывается командной кнопкой Данные о партиях товара.
Эта форма позволяет выполнять следующие операции:
-Выбирать тип товара из списка;
-Открывать формы Полка, Поставщик
-С помощью запроса узнавать о данных товаров для экспорта, о запасах товара.
АРМ Поставщик
Для реализации заказов поставщику в главном меню пользователя имеется вкладка Поставщик (рис.9), которая содержит инструкции и командные кнопки для выполнения заказов поставщикам.
Рис.9. Меню пользователя: вкладка Поставщики
АРМ Покупатели
Для получения информации о поставщиках, а также об отчётах имеется вкладка Покупатели (рис.10).
Рис.10. Меню пользователя: вкладка Покупатели
Рассмотрим более подробно АРМ Заказ, структура остальных АРМ аналогична.
АРМ Заказ
Объекты, составляющие АРМ Заказ, инициируются с помощью командных кнопок вкладки Заказ из меню пользователя (рис.11).
Рис.11. Меню пользователя: вкладка Заказы
Для решения задачи оформления заказов покупателям была разработана форма Заказ (рис. 12), которая открывается с помощью командной кнопки Заказ товаров.
Рис.12. Меню пользователя: вкладка Заказы
Форма Заказ позволяет выполнять следующие операции:
1. Ввод нового заказа; выбор покупателя из имеющегося списка покупателей или с помощью командной кнопки “Открыть форму Покупатель” выполнение перехода в форму Покупатель для ввода нового покупателя (рис.13), где можно открыть форму Тип Покупателя или обновить данные с помощью кнопки Обновить.
Рис.13. Форма Покупатель
2. Выбор формы оплаты заказа с помощью переключателя.
3. Формирование позиций заказа путем выбора имеющихся на складе товаров из списка.
4. Найти свободные места на полках, вычислить прибыль по видам товаров.
5. Автоматическое вычисление стоимости заказа и цены реализации – командная кнопка Стоимость заказа и Установить цену реализации соответственно (запрос на обновление) (рис.14)
Рис.14. Запрос для вычисления цены реализации
6. Запись данных о проданных партиях товаров в архивную таблицу Проданные партии товаров – командная кнопка В архив проданное.
7. Автоматическое удаление сведений о проданных партиях товаров со склада – командная кнопка Удаление записей о проданных партиях.
8. Удаление заказа из базы данных.
В структуре составной формы Заказ имеются следующие формы:
— основная форма Заказ;
— подчиненная форма Пункт_заказа;
— подчиненная форма Стоимость_заказа, реализованная на основе запроса Стоимость_заказа (рис.15)
- Рис.15. Запрос для вычисления стоимости всего заказа
Для удаления текущего заказа из базы данных создан запрос на удаление (рис.16) и макрос для выполнения запроса (рис.17).
Рис.16. Запрос на удаление
Рис.17. Макрос для инициализации выполнения запроса на удаление
Для добавления записей о проданных партиях товаров в архивную таблицу создан запрос на добавление (рис.18).
Рис.18. Запрос на добавление данных в архивную таблицу
Отчёты в базе данных также предоставлены для получения необходимой информации. Примером является отчёт Список заказов и покупателей (рис.19)
Рис.19. Отчёт о списках заказов
Для запуска Меню пользователя создан макрос autoexec (рис.20), позволяющий автоматически открывать главное меню пользователя, сворачивать окно базы данных при открытии файла базы данных.
Рис.20. Макрос autoexec
Вывод
— Все требования по хранению информационных объектов и их реквизитов, описанных в разделе анализа предметной области, выполнены.
— Все требования по управлению данными (добавление, редактирование, удаление, вычисление), описанные в разделе анализа и постановки задачи, выполнены.
— Выполнена автоматизация задач пользователя системы: оформление заказа покупателю, прием партий товаров на склад, формирование отчетности.
Таким образом, можно считать, что, если бы данная база использовалась в складе, она смогла бы упростить работу менеджеров слада, дала возможность надежного хранения информации, быстрого поиска нужных данных.
1Анализ предметной области и постановка задачи. 2
1.1. Назначение системы.. 2
1.2. Описание предметной области. 2
2.Проектирование информационной системы.. 2
2.1. Выбор информационной модели и программного средства ее представления. 2
2.2. Идентификация объектов предметной области и отношений между ними. 2
2.3. Создание модели «сущность-связь». 3
2.4. Нормализация модели данных. 3
2.5. Устранение связей «многие-ко-многим». 4
3.Разработка информационной системы.. 5
3.1. Разработка физической модели базы данных. 5
3.2. Обоснование выбора СУБД для реализации базы данных. 7
3.3. Реализация базы данных средствами выбранной СУБД.. 7
3.4. Создание интерфейса пользователя для автоматизированных рабочих мест. 8
Источник
Устранение связи «многие ко многим»
В качестве примера рассмотрим функционирование фирмы «Столица» (часть варианта 8). Особенностью работы этой фирмы является посредническая деятельность – стыковка поставщиков товаров и покупателей.
Один поставщик связан с несколькими покупателями. Один покупатель, в свою очередь, связан с несколькими поставщиками. По понятным причинам поставщик «не знает» покупателя и наоборот. Вот Вам предпосылка создания связи «многие ко многим» между двумя таблицами: поставщики и покупатели (рис. 3.17).
Как мы уже знаем, реляционная модель не позволяет непосредственно реализовать связь типа «многие ко многим». Кроме этого, штрих-код товара (рис. 1.18), являясь его однозначной идентификацией, не может быть назначен в качестве первичного ключа. В случае если через какое-то время будет закуплена еще одна партия такого же товара, то в таблице «поставщики» появится строчка, имеющая идентичный штрих-код. Аналогичная ситуация возможна и с покупателем, который приобретет такой же товар из другой партии. И еще одна проблема: один клиент практически никогда не покупает всю партию целиком и перед фирмой встает проблема учета остатка товара. Все эти проблемы (реляционной модели и алгоритма) легко решаются добавлением двух промежуточных таблиц: «Поставленные товары» и «Проданные товары». На рис. 1.19 показан фрагмент схемы данных превращения «связи многие ко многим» в несколько связей «один ко многим» с добавлением этих промежуточных таблиц.
Преобразование связи «многие ко многим» в несколько связей «один ко многим» и «много к одному» можно сделать следующим образом. Вместо того чтобы рассматривать множество поставщиков, поставляющих товары
Рис. 1.18 Штрих-код
Рис. 1.19. Работающий фрагмент схемы данных
Источник