Создать базу данных для торгового предприятия

Разработка базы данных для торговой организации

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

Рубрика	Программирование, компьютеры и кибернетика
Вид	курсовая работа
Язык	русский
Дата добавления	18.05.2017
Размер файла	273,5 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

1. Концептуальное проектирование базы данных

1.1 Анализ предметной области

1.2 Постановка задачи

1.3 Описание сущностей и взаимосвязей между ними

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

2.1 Построение отношений базы данных

2.2 Приведение отношений к третьей нормальной форме

2.3 Определение ограничений целостности

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

3.2 Перенос логической модели в среду СУБД

Цель данной курсовой работы разработать базу данных для торговой организации.

Повышение автоматизации данного структурного подразделения является актуальной проблемой. Ее решение позволить значительно повысить производительность труда и надежность информационных процессов.

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

Целью данной курсовой работы является разработка базы данных для торговой организации.

Для достижения цели необходимо выполнить следующие задачи:

— выполнить концептуальное (инфологическое) проектирование, получив модель сущностей и связей;

— выполнить логическое (даталогическое) проектирование, получив логическую модель отношений;

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

Объект исследования — информационная система торговой организации.

Предмет исследования — база данных торговой организации.

логический поле управление postgresql

1. Концептуальное проектирование базы данных

1.1 Анализ предметной области

Предметной областью называется часть реального мира, представляющая интерес для данного исследования (использования).

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

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

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

1.2 Постановка задачи

В рамках данной курсовой работы необходимо разработать базу для торговой организации. Для этого необходимо реализовать три этапа проектирования концептуальное (инфологическое), логическое (дата логическое) и физическое.

На этих этапах необходимо составить общую модель представления данных, перенести эту модель в отношения (таблицы), описать домены атрибутов, реализовать таблицы и связи в конкретной системе управления базами данных.

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

По средствам базы данных необходимо обеспечить надежное хранение, сбор, изменение и использование информации.

Разрабатываемая база данных должна отвечать следующим требованиям:

Модель данных должна быть представлена:

— сущностями — не менее 10;

— связью типа «один- к- одному» — не менее 2;

— связью типа «один- ко- многим» — не менее 6;

— связью типа «многие- ко- многим» — не менее 2;

— описанием атрибутов сущностей и ограничений доменов.

База данных контрольного примера должна иметь суммарный объем не менее 100 кортежей.

1.3 Описание сущностей и взаимосвязей между ними

Модель «сущность-связь» называют также «ER-моделью» (essence-сущность, relation-связь).

Сущность — имеющая смысл в данной предметной области, существующее в действительности или воображаемое явление, информацию о котором нужно сохранять.

В рассматриваемой предметной области можно выделить следующие сущности:

1. Торговая точка — содержит информацию о торговых точках (наименование, тип торговой точки).

2. Тип торговой точки — содержит сведения о типах торговых точек.

3. Сотрудники — содержит основную информацию о сотрудниках (ФИО, торговая точка, тип сотрудника).

4. Тип сотрудника — содержит сведения о типах сотрудников.

5. Продажи — содержит сведения о продажах (покупатель, продукт, сотрудник, количество, стоимость, дата).

6. Покупатель — содержит информацию о покупателях.

7. Поставщик — содержит информацию о поставщиках(страна, тип поставщика).

8. Продукт — информация о продуктах ( тип товара, производитель).

9. Заказы — содержит общие сведения о заказах (сотрудник, каталог, количество, дата).

10. Каталог — сведения о ценах на товары (поставщик, продукт, цена).

11. Страна — список стран.

12. Тип поставщика — список типов поставщиков.

13. Тип товара — список типов товаров.

14. Производитель — список производителей.

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

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

2. Связь один ко многим (1:М) одному экземпляру первой сущности может соответствовать несколько экземпляров второй сущности, но не наоборот.

3. Связь многие ко многим (М:М) одному экземпляру первой сущности может соответствовать несколько экземпляров второй сущности и наоборот. Данная связь реализуется с помощью дополнительной сущности которая называется ассоциативной.

Рассмотрим связи между выявленными сущностями:

1. Один к одному: отсутствуют.

2. Один ко многим: Тип сотрудника — Сотрудник, Тип торговой точки — Торговая точка, Тип поставщика — Поставщик, Страна — Поставщик, Торгоная точка — Сотрудник, Продукт — Каталог, Каталог — Заказы, Персонал — Заказы.

3. Многие ко многим: Сотрудник — Покупатель, Продукт — Покупатель, Производитель — Тип товара.

Концептуальная модель данных в виде ER-диаграммы представлена на рисунке 1.

Рисунок 1 — Концептуальная модель данных

Выводы

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

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

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

Произведено описание сущностей и взаимосвязей между ними. Предметная область представлена двенадцатью стержневыми сущностями и двумя ассоциативными сущностями.

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

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

2.1 Построение отношений базы данных

Реляционная модель баз данных была предложена сотрудником фирмы IBM Э. Кодом в начале 70-х годов. Будучи математиком, он предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность и Декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известных в математике как отношения.

Одна из главных идей заключается в том, что связи между данными должны устанавливаться в соответствии с их внутренними логическими взаимоотношениями.

Реляционная БД представляет собой информацию об объекте, представленную в виде двумерного массива — таблицы объединенных определенными связями.

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

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

Атрибут представляющий собой копию ключа другого отношения называется внешним ключом. Реляционная модель накладывает на внешние ключи ограничения для обеспечения целостности данных. Это означает, что каждому значению внешнего ключа должны соответствовать строки в связываемых отношениях.

2.2 Приведение отношений к третьей нормальной форме

В данной курсовой работе применен метод отображения ER-диаграммы на логическую схему. При этом необходимо следовать правилам отображения:

— каждая сущность становится отношением (таблицей); идентификатор сущности становится первичным ключом, а его характеристики атрибутами отношения (столбцами);

— связь «один ко многим» не образует нового отношения, но идентификатор главной сущности становится внешним ключом младшей сущности;

— связь «многие ко многим» образует новое отношение, идентификаторы связываемых сущностей становятся составным первичным ключем нового отношения.

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

Если имеется связь один к одному, то необходимо внимательно изучить эту связь и определить имеет ли смысл объединить эти две сущности в одну.

Полученная логическая модель, полученная отображением ER-диаграммы, представлена на рисунке 2.

В соответствии с правилами отображения сущность Торговая точка представляется отношением outlet, Тип торговой точки — type_outlet, Сотрудники — personal, Тип сотрудника — type_ personal, Продажи — selling, Покупатель — buyer, Продукт — product, Заказы — order, Каталог — catalor, Поставщики — supplier, Страна — country, Тип поставщика — type_ supplier, Тип товара — type_product, Производитель — maker.

Рисунок 2 — Логическая модель

2.3 Определение ограничений целостности

Описание таблиц базы данных и их полей представлено в таблице 1.

Таблица 1 — Домены атрибутов отношений базы данных «Торговая организация».

outlet — Содержит основные сведения о торговых точках

Источник

Создать базу данных для торгового предприятия

База данных Access Торговая фирма

База данных Access Торговая фирма

1. Разработать однотабличную БД ТОРГОВАЯ ФИРМА для автоматизированного контроля продаж товаров торговой фирмы.
2. БД должна содержать таблицу Продажа товаров со следующей структурой записи: Дата продажи, Товар, Сумма, Скидка, Оплата (логическое поле), Филиал, Менеджер. Поле Товар заполнить наименованиями: Товар А, Товар В, Товар С.
3. Обеспечить контроль ввода данных по полю Скидка (для заполнения поля использовать подстановку из списка значений: 0%, 3%, 5%, 10%) и полю Филиал (Филиал 1, Филиал 2).
4. Ввод данных в таблицу выполнить посредством формы в один столбец.
5. БД должна обеспечивать получение информации о продаже товаров:
• по наименованию товара;
• по фамилии менеджера;
• по номеру филиала;
• со скидкой 5%, на которые счет не был оплачен.
6. С помощью запроса с вычисляемым полем рассчитать НДС в размере 15% от суммы оплаты.
7. Разработать отчет Ведомость продаж по запросу НДС, с группировкой записей по филиалам и фамилиям менеджеров (в алфавитном порядке) с расчетом итоговых значений суммы и НДС.

База данных Access Торговая фирма содержит 1 таблицу, 5 запросов, 1 форма, 1 отчет.

Пояснительной записки нет!

Таблица «Продажа товаров» — База данных Access Торговая фирма

Запрос «Продажи менеджера» — База данных Access Торговая фирма

Запрос «Продажи филиала» — База данных Access Торговая фирма

Запрос «Расчет НДС» — База данных Access Торговая фирма

Форма «Продажа товаров» — База данных Access Торговая фирма

Отчет «Ведомость продаж» — База данных Access Торговая фирма

Цель практических заданий – приобретение навыков анализа предметной области, проектирования базы данных, ее физической реализации в СУБД Access.
Результат выполнения работы представляется в виде базы Access, который должен содержать:
• структуру спроектированных таблиц,
• примеры форм, обеспечивающих интерфейс пользователя,
• запросы (в режиме Конструктора и на языке SQL),
• отчеты (в режиме отчета и в режиме Конструктора).

Готовая база данных БД Access Торговая фирма доступна для скачивания по ссылке ниже.

Источник