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

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

Введение

Введение

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

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

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

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

Выводы

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

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

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

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

Выводы

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

3.1 Выбор СУБД

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

Выводы

Заключение

Список литературы

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLeon) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель "сущность--связь", предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена "сущность--связь", или "Entity Relationship", стала фактическим стандартом при инфологическом моделировании баз данных.

Модель «сущность-связь» называют также «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 - Содержит основные сведения о торговых точках
1	id_outlet	bigint (AutoInc)	Код торговой точки	Primary
2	name	text	Название торговой точки
3	id_type_outlet	bigint	Код типа торговой точки	Foreign
type_outlet - Сведения по типам торговых точек
1	type_outlet	bigint (AutoInc)	Код типа торговой точки	Primary
2	name	text	Название типа торговой точки
personal - Основные сведения о сотрудниках
1	id_ personal	bigint (AutoInc)	Код сотрудника	Primary
2	fio	text	ФИО
3	id_outlet	bigint	Код торговой точки	Foreign
4	id_type_ personal	bigint	Код типа сотрудника	Foreign
type_ personal - Сведения о типах сотрудника
1	id_type_ personal	bigint (AutoInc)	Код типа сотрудника	Primary
2	name	text	Название типа сотрудника
selling - Сведения о продажах
1	id_ selling	bigint (AutoInc)	Код продажи	Primary
2	id_ product	bigint	Код продукта	Foreign
3	id_ personal	bigint	Код сотрудника	Foreign
4	count	bigint	Количество
5	amount	float	Сумма
6	date	date	Дата
buyer - Сведения о покупателях
1	id_ buyer	bigint (AutoInc)	Код покупателя	Primary
2	name	text	ФИО
product - Виды продукта
1	id_ product	bigint (AutoInc)	Код вида продутка	Primary
2	id_type_product	bigint	Код тип продукта	Foreign
3	id_maker	bigint	Код производителя	Foreign
order - Сведения о заказах
1	id_ order	bigint (AutoInc)	Код заказа	Primary
2	id_personal	bigint	Код сотрудника	Foreign
3	id_ catalog	bigint	Код каталога	Foreign
4	count	bigint	Количество
5	date	date	Дата
6	status	text	Статус заказа
catalog - сведения о ценах на товары
1	id_ catalog	bigint (AutoInc)	Код каталога	Primary
2	id_ supplier	bigint	Код поставщика	Foreign
3	id_ product	bigint	Код продукта	Foreign
4	cost	float	Цена
supplier - Сведения о поставщиках
1	id_supplier	bigint (AutoInc)	Код поставщика	Primary
2	id_country	bigint	Код страны	Foreign
3	id_type_supplier	bigint	Код типа поставщика	Foreign
type_supplier - типы поставщиков
1	id_type_supplier	bigint (AutoInc)	Код типа поставщика	Primary
2	name	text	Наименование
country - Сведения о странах
1	id_country	bigint (AutoInc)	Код страны	Primary
2	name	text	Наименование
type_product - тип продукта
1	id_ type_product	bigint (AutoInc)	Код страны	Primary
2	name	text	Наименование
Maker - список производителей
1	id_maker	bigint (AutoInc)	Код страны	Primary
2	name	text	Наименование

Выводы

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

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

Определены ограничения целостности и домены атрибутов отношений.

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

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

3.1 Выбор СУБД

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

- обеспечивать получение общих и/или детализированных отчетов по итогам работы;

- позволять легко определять тенденции изменения важнейших показателей;

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

- выполнять точный и полный анализ данных.

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

Среди наиболее ярких представителей систем управления базами данных можно отметить: PostgreSQL, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle. Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще - диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

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

В рамках данной курсовой работы будет использована СУБД PostgreSQL.

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

Перенеся логическую модель в систему управления базами данных PostgreSQL получают физическую модель базы данных.

Физическая модель базы данных представлена на рисунке 3.



Рисунок 3 - Физическая модель базы данных

Выводы

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

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

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

Заключение

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

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

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

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

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

Список литературы

1. Голицына О.Л., Максимов Н.В. - Базы данных. - М.: Форум - Инфра М, 2003. - 352 с.

2. Горев А., Макашарипов С. Эффективная работа с СУБД. - С-Пб.: Питер,

1997. - 254 с.

3. Вирт Н. Алгоритмы и структуры баз данных. - М.: Мир, 1989. - 196с.

4. Дейт К.Дж. Введение в системы баз данных. - М.: Вильямс, 2001. - 354 с.

5. Диго С.М. Проектирование и использование баз данных. Учебник. - М.: Финансы и статистика, 1995. - 420 с.

6. Зиндер Е.З. Проектирование баз данных: новые требования, новые подходы. - М.: Мир, 1996. - 287 с.

7. Цикритзис Д., Лоховски Ф. Модели данных. - М.: Финансы и статистика, 1985. - 366 с.

8. Карпова Т.С. Базы данных : модели, разработка, реализация. - С-Пб.: Питер, 2001. - 458 с.

Размещено на Allbest.ru

...