Ирина Эланс

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

Автоматизированный учет заказов в мебельном салоне

Кафедра: «Прикладная информатика в экономике»

КУРСОВОЙ ПРОЕКТ

По дисциплине: Базы данных

На тему: “ Автоматизированный учет заказов в мебельном салоне».

Работу выполнил:

студент гр.

Номер зачетной книжки:

Проверил:

Тольятти 2011 г.

Содержание

Введение………………………………………………………………………………………….3

Аналитическая часть……………………………………………………………………..5

Описание предметной области………………………………………………....5

Объект проектирования……………………………………………………...5
Информационные процессы…………………………………………………5

Требование к ИС…………………………………………………………………6

Проектирование базы данных…………………………………………………………...7

Проектирование информационной модели базы данных…………………….7
Построение логической модели базы данных…………………………………9
Построение физической модели данных……………………………………..13
Создание базы данных……...………………………………………………….17

Создание приложения для работы с базой данных…………………………………...19

Заключение……………………………………………………………………………………...31

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

Приложения:

1. Листинг………………………………………………………………………...33

2. Инструкция по работе с программой…………………….……………….…40

Введение.

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

- повышение эффективности труда (экономию времени на обработке информации);

- уменьшение затрат на содержание сотрудников, что приводит к удешевлению продукции;

- способность быстро анализировать и строить прогнозы (мгновенное получение отчетов).

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

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

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

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

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

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

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

1. Аналитическая часть.

Описание предметной области.

1.1.1 Объект проектирования

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

1.1.2 Информационные процессы

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

Рис.1 Схема бизнес-процесса мебельного салона

Для регистрации клиентов и их заказов используется «регистрационная книга», а предлагаемая продукция находится в каталогах, которые предоставлены производителями. Разрозненность информации делает работу менеджера долгой и малоэффективной, что влечет за собой увеличение времени, затрачиваемого на регистрацию заказа, а если клиент оформляет второй или последующий заказ, то возникает путаница в «регистрационной книге», где одна фамилия фигурирует много раз, делая последующий поиск трудным занятием. К тому же ручная работа менеджера не прибавляет солидности предприятию, а, наоборот, формирует мнение клиента о салоне, как о несостоятельной организации. Использование же общедоступных решений для ввода и хранения данных, например Microsoft Excel, будет не самым правильным выбором, т.к. отсутствует возможность синхронизировать информацию разного рода, например, клиент-заказ-производитель. Поэтому очевидна потребность «Мебельного салона» в централизованной системе управления информацией, способной облегчить труд сотрудника по учету и регистрации заказов и сократить время обслуживания клиента.

Требования к ИС.

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

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

Разрабатываемая для мебельного салона информационная система должна удовлетворять предъявляемым к ней требованиям:

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

Информационная система должна повысить качество сервиса для клиентов фирмы и позволить менеджеру оперативно регистрировать и согласовывать заказы.

2. Проектирование базы данных.

2.1. Проектирование информационной модели базы данных.

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

База данных (БД) — именованная совокупность данных, отражающая состояние

объектов и их отношений в рассматриваемой предметной области.

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

Изучив работу менеджера по учету заказов определим информационные объекты для дальнейшей разработки базы данных:

клиент;
заказ;
товар.

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

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

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

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

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

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

Сущность (Entity) – собирательное понятие, некоторая абстракция реально существующего объекта, процесса или явления рассматриваемого предметной области о котором необходимо хранить информацию.

Определим сущности для нашей модели: клиент, заказ, товар.

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

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

Основные предметно-значимые атрибуты имеющихся сущностей:

КЛИЕНТ - фамилия, имя, отчество, телефон;
ЗАКАЗ - дата заказа, дата поставки, информация;
ТОВАР - наименование, цена, производитель, расчетный счет производителя, контактный телефон производителя.

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

Связь (Relationship) – средство представления отношения между сущностями.

На «Рис.2» представлены три вида связи: один-к-одному, один-ко-многим, много-ко-многим.

1 1 1 М М М

Рис.2 Виды связей

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

Обозначенные на «Рис.3» связи между сущностями показывают, что:

- один клиент может сделать много заказов (один-ко-многим);

- заказ оформляется только на один товар (один-к-одному);

Рис.3 Концептуальная модель

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

2.2. Проектирование логической модели данных.

Вторым этапом в проектировании базы данных является построение логической модели данных.

Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных.

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

Отношение – это плоская таблица, состоящая из столбцов и строк.

Атрибут - это поименованный столбец отношения.

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

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

В реляционной модели отношения используются для хранения информации об

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

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

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

Первая нормальная форма требует, чтобы каждое поле таблицы БД было

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

Вторая нормальная форма требует, чтобы все поля таблицы зависели от

первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не

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

ключевых полей от части первичного ключа, следует выделить их в отдельную таблицу,

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

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

Третья нормальная форма требует, чтобы в таблицах не имелось транзитивных

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

входящего в первичный ключ, не зависело от значения другого поля, также не входящего

в первичный ключ.

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

КЛИЕНТ

Фамилия	Имя	Отчество	Телефон
Иванов	Иван	Иванович	222-22-22

ЗАКАЗ

Дата заказа

Дата поставки

Информация

10.12.2010

21.12.2010

материал - сталь

обивка - кожа

ТОВАР

Наименование	Цена	Производитель	Расчетный счет	Контактный телефон
Стул	12000	Томск Мебель	000002589743001420123	333-33-33

Поскольку один производитель может выпускать много товаров (т.е. единиц мебели, например стул, стол, диван), то неизбежно повторение в столбцах производитель расчетный счет, контактный телефон. Такая структура записи данных не подходит для реляционной базы данных и запись приведенной информации не соответствует требованиям первой нормальной формы, поскольку содержит повторяющуюся группу столбцов. Поэтому эту таблицу разделим на две: ТОВАР и ПРОИЗВОДИТЕЛЬ.

ТОВАР

Наименование	Цена
Стул	12000

ПРОИЗВОДИТЕЛЬ

Фирма	Расчетный счет	Контактный телефон
Томск Мебель	000002589743001420123	333-33-33

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

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

для таблицы КЛИЕНТ – это № клиента;
для таблицы ЗАКАЗ – это № заказа;
для таблицы ТОВАР – это № производителя.

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

Внешний ключ содержит значения связанного с ним поля, являющегося первичным ключом.

для таблицы ЗАКАЗ – это № клиента, № товара;
для таблицы ТОВАР – это № товара;
для таблицы ПРОИЗВОДИТЕЛЬ – это № производителя.

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

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

После расстановки ключевых полей организуем связи между отношениями (таблицами) и получаем реляционную модель «рис.4».

Рис. 4 Логическая модель

На «рис.4» связь между таблицами обозначены в виде стрелок с указателями:

1 М - связь один-ко-многим;
1 1 - связь один-к-одному.

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

2.3. Построение физической модели данных

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

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

Database Desktop - это редактор файлов баз данных dBASE и Paradox от фирмы Borland.

Создадим физическую модель наших данных в формате таблиц Paradox:

Рис.5 Физическая модель

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

Таблица meb_client.dbf для размещения данных о клиентах салона.

Название поля (Fields name)	Наименование поля	Тип (Type)	Длина	Назначение
N_cli	№ клиента	I (Long Integer) целое число	целое	Поле для хранения номера клиента, является ключевым, т. к. содержит уникальную идентификацию записей и служит для точного разделения значений. Каждая запись имеет свой неповторяющийся номер.
Fam	Фамилия	A (Alpha) строковое поле	30	Поле для хранения фамилии клиента
Name	Имя	A (Alpha) строковое поле	30	Поле для хранения имени клиента
Otch	Отчество	A (Alpha) строковое поле	30	Поле для хранения отчества клиента
Tel	Телефон	A (Alpha) строковое поле	30	Поле для хранения номера телефона клиента

Таблица meb_zacaz.dbf для размещения данных о заказах салона.

Название поля (Fields name)	Наименование поля	Тип (Type)	Длина	Назначение
N_zac	№ заказа	+ (Autoincrement) целое число	При добавлении к таблице очередной записи в поле записывается число на единицу большее, чем находится в соответствующем поле последней добавленной записи	Поле для хранения номера заказа
N_cli	№ клиента	I (Long Integer) целое число	целое	Поле для хранения номера клиента
N_meb	№ мебели	I (Long Integer) целое число	целое	Поле для хранения номера товара
Dat_zac	Дата заказа	D (Date) дата	дд/мм/гггг	Поле для хранения даты заказа
Dat_post	Дата поставки	D (Date) дата	дд/мм/гггг	Поле для хранения даты поставки товара клиенту
Dop_info	Информация	A (Alpha) строковое поле	200	Поле для хранения информации о заказе

Название поля (Fields name)

Наименование поля

Тип (Type)

Длина

Назначение

N_meb

№ мебели

I (Long Integer) целое число

целое

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

Naimenovanie

Наименование товара (мебели)

A (Alpha) строковое поле

Поле для хранения названия товара (мебели)

Cena

Цена

$ (Money) число в денежном формате

целое

Поле для хранения цены товара (мебели)

N_pro

№ производителя

I (Long Integer) целое число