Устранение связей «многие-ко-многим»
В модели Склад присутствует связь «многие-ко-многим» между сущностями Полка и Товар. Устранение этой связи требует создания межсекционной сущности. По смыслу, имя такой межсекционной сущности может быть Партия_товара. Так как в модели уже присутствует сущность Партия_товара, то в целях устранения избыточности хранения данных, эта сущность может быть использована в качестве межсекционной при устранении связи «многие-ко-многим». Результат устранения множественной связи показан на рис. 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
Источник
Связь многие ко многим как избавиться
Базы данных могут содержать таблицы, которые связаны между собой различными связями. Связь (relationship) представляет ассоциацию между сущностями разных типов.
При выделении связи выделяют главную или родительскую таблицу (primary key table / master table) и зависимую, дочернюю таблицу (foreign key table / child table). Дочерняя таблица зависит от родительской.
Для организации связи используются внешние ключи. Внешний ключ представляет один или несколько столбцов из одной таблицы, который одновременно является потенциальным ключом из другой таблицы. Внешний ключ необязательно должен соответствовать первичному ключу из главной таблицы. Хотя, как правило, внешний ключ из зависимой таблицы указывает на первичный ключ из главной таблицы.
Связи между таблицами бывают следующих типов:
Один к одному (One to one)
Один к многим (One to many)
Многие ко многим (Many to many)
Связь один к одному
Данный тип связей встречает не часто. В этом случае объекту одной сущности можно сопоставить только один объект другой сущности. Например, на некоторых сайтах пользователь может иметь только один блог. То есть возникает отношение один пользователь — один блог.
Нередко этот тип связей предполагает разбиение одной большой таблицы на несколько маленьких. Основная родительская таблица в этом случае продолжает содержать часто используемые данные, а дочерняя зависимая таблица обычно хранит данные, которые используются реже.
В этом отношении первичный ключ зависимой таблицы в то же время является внешним ключом, который ссылается на первичный ключ из главной таблицы.
Например, таблица Users представляет пользователей и имеет следующие столбцы:
UserId (идентификатор, первичный ключ)
Name (имя пользователя)
И таблица Blogs представляет блоги пользователей и имеет следующие столбцы:
BlogId (идентификатор, первичный и внешний ключ)
Name (название блога)
В этом случае столбец BlogId будет хранить значение из столбца UserId из таблицы пользователей. То есть столбец BlogId будет выступать одновременно первичным и внешним ключом.
Связь один ко многим
Это наиболее часто встречаемый тип связей. В этом типе связей несколько строк из дочерний таблицы зависят от одной строки в родительской таблице. Например, в одном блоге может быть несколько статей. В этом случае таблица блогов является родительской, а таблица статей — дочерней. То есть один блог — много статей. Или другой пример, в футбольной команде может играть несколько футболистов. И в то же время один футболист одновременно может играть только в одной команде. То есть одна команда — много футболистов.
К примеру, пусть будет таблица Articles, которая представляет статьи блога и которая имеет следующие столбцы:
ArticleId (идентификатор, первичный ключ)
BlogId (внешний ключ)
Title (название статьи)
Text (текст статьи)
В этом случае столбец BlogId из таблицы статей будет хранить значение из столбца BlogId из таблицы блогов.
Связь многие ко многим
При этом типе связей одна строка из таблицы А может быть связана с множеством строк из таблицы В. В свою очередь одна строка из таблицы В может быть связана с множеством строк из таблицы А. Типичный пример — студенты и курсы: один студент может посещать несколько курсов, и соответственно на один курс могут записаться несколько студентов.
Другой пример — статьи и теги: для одной статьи можно определить несколько тегов, а один тег может быть определен для нескольких статей.
Но в SQL Server на уровне базы данных мы не можем установить прямую связь многие ко многим между двумя таблицами. Это делается посредством вспомогательной промежуточной таблицы. Иногда данные из этой промежуточной таблицы представляют отдельную сущность.
Например, в случае со статьями и тегами пусть будет таблица Tags, которая имеет два столбца:
TagId (идентификатор, первичный ключ)
Text (текст тега)
Также пусть будет промежуточная таблица ArticleTags со следующими полями:
TagId (идентификатор, первичный и внешний ключ)
ArticleIdId (идентификатор, первичный и внешний ключ)
Технически мы получим две связи один-ко-многим. Столбец TagId из таблицы ArticleTags будет ссылаться на столбец TagId из таблицы Tags. А столбец ArticleId из таблицы ArticleTags будет ссылаться на столбец ArticleId из таблицы Articles. То есть столбцы TagId и ArticleId в таблице ArticleTags представляют составной первичный ключ и одновременно являются внешними ключами для связи с таблицами Articles и Tags.
Ссылочная целостность данных
При изменении первичных и внешних ключей следует соблюдать такой аспект как ссылочная целостность данных (referential integrity). Ее основная идея состоит в том, чтобы две таблице в базе данных, которые хранят одни и те же данные, поддерживали их согласованность. Целостность данных представляет правильно выстроенные отношения между таблицами с корректной установкой ссылок между ними. В каких случаях целостность данных может нарушаться:
Аномалия удаления (deletion anomaly). Возникает при удалении строки из главной таблицы. В этом случае внешний ключ из зависимой таблицы продолжает ссылаться на удаленную строку из главной таблицы
Аномалия вставки (insertion anomaly). Возникает при вставке строки в зависимую таблицу. В этом случае внешний ключ из зависимой таблицы не соответствует первичному ключу ни одной из строк из главной таблицы.
Аномалии обновления (update anomaly). При подобной аномалии несколько строк одной таблицы могут содержать данные, которые принадлежат одному и тому же объекту. При изменении данных в одной строке они могу прийти в противоречие с данными из другой строки.
Аномалия удаления
Для решения аномалии удаления для внешнего ключа следует устанавливать одно из двух ограничений:
Если строка из зависимой таблицы обязательно требует наличия строки из главной таблицы, то для внешнего ключа устанавливается каскадное удаление. То есть при удалении строки из главной таблицы происходит удаление связанной строки (строк) из зависимой таблицы.
Если строка из зависимой таблицы допускает отсутствие связи со строкой из главной таблицы (то есть такая связь необязательна), то для внешнего ключа при удалении связанной строки из главной таблицы задается установка значения NULL. При этом столбец внешнего ключа должен допускать значение NULL.
Аномалия вставки
Для решения аномалии вставки при добавлении в зависимую таблицу данных столбец, который представляет внешний ключ, должен допускать значение NULL. И таким образом, если добавляемый объект не имеет связи с главной таблицей, то в столбце внешнего ключа будет стоять значение NULL.
Аномалии обновления
Для решения проблемы аномалии обновления применяется нормализация, которая будет рассмотрена далее.
Источник