Создание базы данных для Интернет-магазина компьютерных комплектующих

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

КУРСОВАЯ РАБОТА

на тему: «Создание базы данных для Интернет-магазина компьютерных комплектующих»

Дисциплина: Базы данных

2013

ВВЕДЕНИЕ

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

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

- создать ER-диаграммы;

- создать базы данных в соответствии с ER-диаграммой;

- связать с языков программирования для дальнейшего создания оболочки для этой базы данных;

- построить формы через выбранный язык программирования;

Создания и контроль за процессами по управлению базой данных осуществляет СУБД (система управления базами данных). Для данной работы была выбрана система управления базами данных, включенный в стандартный пакет программного обеспечения под Windows - Microsoft Office Access 2007. Для моделирования ER-диаграмм бизнес процессов использована программа Bpwin и вэб-сайт www.draw.io. Уже для создания самой оболочки базы данных используется язык программирования Borland Delphi 7, которой связывается с база данных, расположенной в Access.

1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

Одни из наиболее популярных семантических (формализирующих значения конструкций языков программирования посредством построения их формальных математических моделей) моделей данных - модели «Сущность-Связь» (часто их называют кратко ER-моделью от Entity-Relationship, где еntity - сущность и relationship - связь, отношение). Поэтому в русскоязычной литературе ER-модель иногда называют моделью сущность-отношение, а иногда и реляционной семантической моделью. На использовании разных вариантов моделей сущность-отношение основано большинство современных подходов к проектированию баз данных (главным образов, реляционных).

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

Первостепенной задачей было определено создание ER-диаграмм для облегчения понимания самого принципа хранения данных в базах данных. Для этого необходимо определить 3 основные понятия ER-модели. Ими являются сущность, связь и атрибут. Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступной. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. Связь - это графически изображаемая ассоциация, устанавливаемая между двумя типами сущностей. Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. интернет магазин delphi диаграмма

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

BPwin позволяет:

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

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

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

BPwin поддерживает 3 методологии - методологии функционального моделирования (IDEF0), потоков данных (DFD) и потоков работ (IDEF3). BPwin позволяет повторно использовать ключевую информацию моделирования с точки зрения базовых аспектов, чтобы определить точки конфликтов и, в конечном счете, достичь их согласования. На рисунке 1 представлена модель IDEF0. С помощью функционального моделирования (нотация IDEF0) можно провести систематический анализ бизнеса, сосредоточившись на регулярно решаемых задачах (функциях), свидетельствующих об их правильном выполнении показателях, необходимых для этого ресурсах, результатах и исходных материалах (сырье).

Рисунок 1. Описание бизнес-процессов в нотации IDEF0.

Как видно на первом рисунке главным рассматриваемым процессом является продажа в данном случае товаров. Как правило в левую грань прямоугольника входят объекты, обеспечивающие сам процесс торговли: товар от поставщиков и заказы клиентов и сопроводительная документация. Под сопроводительной документацией понимаются: формы заполнения заявки, чеки на полученную и проданную продукцию, прайс-листы. В существующем проекте такая таблица не существует, так как основная задача это создание базы данных, а не информационной системы. Стрелки управления, заходящие в верхнюю грань, указывают на влияние состояния рынка и законов, регулирующих предпринимательскую деятельность на существующий бизнес процесс. Механизмами исполнения, заходящие снизу, являются: персонал, клиенты, поставщики и оборудование, обеспечивающее все это функционирование. И на выходе (правая грань): денежные средства (чистая прибыль), документы, доставленный товар и отзывы клиентов об обслуживании и товаре. Рисунок 1 дает возможность получения четкого представления информации по исполнению бизнес-процессов по работе данного Интернет-магазина. В дальнейшем это позволить создать ER-диаграмму. Но на данном этапе еще необходимо создать модель DFD (модель потоков данных), которая часто используется при разработке программного обеспечения и сосредоточена вокруг потоков данных, передающихся между различными операциями, включая их хранение, для достижения максимальной доступности и минимального времени ответа. Такое моделирование позволяет рассмотреть конкретный процесс, проанализировать операции, из которых он состоит, а также точки принятия решений, влияющих на его ход. Чаще всего диаграммы этой нотации не являются самостоятельными, а используются как дополнения к модели бизнес-процессов, построенной в IDEF0.

Всего DFD использует четыре важных элемента:

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

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

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

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

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

Модель, выполненная в IDEF3, может содержать следующие элементы:

Единицы работы (Unit of Work) - основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0.

- Связи (Links) - в IDEF3 это и есть стрелки, показывающие взаимоотношение процессов;

- перекрестки (Junctions) - изображаются в виде разветвления или слияния стрелок, позволяет показать логические отношения между процессами и возможные альтернативные пути развития процесса. Существует два типа перекрестков: перекресток слияния и перекресток ветвления (Fan-out Junction) - узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно;

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

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

Ниже представлена модель DFD (рисунок 2).

Рисунок 2. Описание бизнес-процессов в нотации DFD.

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

Уже на основе двух описанных выше моделей BPWin, можно построить реляционную модель данных, позволяющую выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. В прямоугольниках указаны сущности, в овалах - атрибуты. Подчеркнутые слова - это первичные ключи (поле или набор полей таблицы, которые предоставляют базе данных уникальный идентификатор для каждой строки; при помощи первичных ключей и отношений между таблицами выбирается способ, которым сведения будут объединены вновь. Поля первичного ключа используются в базе данных для быстрого сопоставления данных из нескольких таблиц и для объединения этих данных по заданному принципу), которые понадобятся для связывания таблиц и выполнения запросов. В ромбах указаны действия, которые связывают наши объекты. Непосредственно в базе данных они ни как не учитываются, а служат лишь наглядным примером в диаграмме. Более толстые линии показывают связь между столбцами, эти связи будут использованы при создании запросов в Microsoft Office Access.

Рисунок 3. ER-диаграмма Интернет-магазина.

2. ПРАКТИЧЕСКАЯ ЧАСТЬ

2.1 Работа со средой Microsoft Office Access

Microsoft Office Access или просто Microsoft Office -- реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных. Для дальнейшей работы со средой программирования Borland Delphi 7 необходим формат хранения базы данных .mdb возможный в версии Microsoft Access 2002-2003. В более поздних же версиях данного программного обеспечения используются иные форматы, но также предусмотрена возможность сохранения базы данных в форматах ранних версий, что и необходимо.

Ориентируясь на созданную и описанную ранее модель «сущность-отношение», появилась возможность приступить непосредственно к созданию самой БД в Access. Для начала необходимо создать определенное раньше по ER-диаграмме количество таблиц. Их получается 4: Клиенты, Персонал, Поставщики и Товар (рисунки 3-6).

Рисунок 3. Первая таблица БД.

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

Рисунок 4. Вторая таблица БД.

Таблица Персонал представлена 6 столбцами. Как и каждый клиент, всякий сотрудник имеет свой номер. Далее располагается информация по его ФИО, занимаемой им должности и получаемой зарплате.

Рисунок 5. Третья таблица БД.

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

Рисунок 6. Четвертая таблица БД.

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

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

Рисунок 7. Пятая таблица БД.

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

Рисунок 8. Модель схемы данных БД в Access.

2.2 Работа на языке программирования Borland Delphi 7.0

Borland Delphi --интегрированная среда разработки ПО для Microsoft Office, Mac OS, iOS и Android на языке Delphi (ранее носившем название Object Pascal). Embarcadero Delphi является частью пакета Embarcadero RAD Studio и поставляется в четырёх редакциях: Starter, Professional, Enterprise и Architect. В данной работе используется редакция Borland Delphi 7 Enterprise.

Delphi 7, выпущенная в августе 2002 года, стала стандартном для многих разработчиков Delphi. Это один из самых успешных продуктов Borland из-за стабильности, скорости и низких требований к аппаратному обеспечению. В Delphi 7 добавлены новые компоненты для Windows XP и увеличено число компонентов для создания Web-приложений.

Далее на рисунке 9 представлено само программное обеспечение Borland Delphi 7. Интерфейс его достаточно интуитивен и дружелюбен к пользователю. Кроме связки языка программирования непосредственно с самой базой данных здесь осуществляется и реализация интерфейса оболочки программы-базы данных.

Рисунок 9. Интерфейс Borland Delphi 7.

Для этого необходимо предпринять следующие шаги: на основной панели выбрать вкладку ADO, на которой нужно воспользоваться функцией ADOConnection. И после того как вы выбрали данный пункт, необходимо сделать клик на форме, которую мы ходим связать с нашей базой данных. Затем в поле ConnectionString выбрать из множества возможных типов подключения Microsoft Jet 4.0 OLE DP Provider, после чего на следующей вкладке этого окна указать связываемую базу данных. Двойной ОК, и теперь в поле Loginprompt определить значение как ложь, чтобы в дальнейшем не указывать всякий раз пароль и логин доступа к базе данных.

Рисунок 10. Добавление элементов связки БД с Delphi.

Из того же окна, откуда мы брали ADOConnection, мы берем ADOQuery, в одной из полей которого мы выбираем Connection - ADOConnection. Этот элемент позволяет нам осуществлять чтение, выполнение, запись в нашей БД. После чего мы устанавливаем в свойствах этого элемента в ячейке SQL следующий код (Рисунок 11):

Рисунок 11. Выборка всех столбцов одной из таблиц для дальнейшего отображения в БД.

Далее на форме располагается элемент Data Source вкладки Data Access, в которой в поле DataSet выбирается ADOQuery. Для отображения содержимого на форме используется элемент DBGrid закладки DataControls. Результат операций, описанных выше, приведет к следующему (Рисунок 12).

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

Затем на форму кидаются 4 элемента BitBtn панели Additional. Это будущие кнопки данной формы. Как видно на рисунке 13 названия кнопок, задаваемые в поле Caption, и, следовательно, их функционал следующие: добавление новой записи в таблицу, ее изменение, и две еще не переименованные кнопки - удалить (запись из таблицы) и кнопка возврата на главную форму, о которой будет дана информации дальше по работе.

Рисунок 13. Добавление кнопок на панель.

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

Рисунок 14. Вид второй формы.

На рисунке 14 отображено содержание формы ввода и изменения записей после всех действий, описанных в предыдущем абзаце, а также были добавлены подписи к каждому окошку ввода в соответствии со столбцами таблицы, к которой привязана первая форма. Далее были добавлены два элемента BitBtn, которые сразу были переименованы в ОК и Назад, для возврата к первой форме.

После чего появляется необходимость связки второй формы со первой. Это осуществляется следующим образом: например, на кнопку Назад мы прописываем такой код путем двойного клика по этому элементу «Form1.Show;». После чего необходимо запустить проект, и тогда среда программирования автоматически спрашивает, не связать ли ей обе формы (Рисунок 15).

Рисунок 15. Связка двух форм.

Теперь для каждого элемента DBEdit в поле DataSource выбрать тот источник информации, который имеется на первой форме. А в поле DataField выбрать тот столбец, ввод в которой мы хотим осуществить. Когда работа со всеми элементами завершена, можно закончить со второй формой, предварительно прописав событие на кнопку ОК. Код выглядит так: «Form1.ADOQuery1.Post; close;».

Далее остается закрепить события на кнопки, расположенными на первой форме. Для кнопки Добавить это «Form2.show; ADOQuery1.Insert;», для Изменить просто «Form2.show». Для изменений значений строк необходимо выбрать ее из списка, и после нажатия кнопки открывается вторая форма с заполненными полями всех DBEdit готовая к редактированию. На операцию удаления код такой: «ADOQuery1.Delete;». Сейчас можно запустить проект, и тогда будет предложено связать первую форму со второй.

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

Он делается следующим образом. На вкладке Standart выбрать функцию Edit и кинуть на форму 1 в количестве двух штук для поиска по фамилии клиента и по предоставленной ему скидке (Рисукок 16). Рядом добавляем подписи, чтобы было понятно, в какое окно надо вводить текст для поиска интересующего пользователя параметра.

Рисунок 16. Запросы первой формы.

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

Рисунок 17. Конечный вид первой формы.

Данный алгоритм операций нужно выполнить для каждой таблицы в нашей базе данных. В нашем случае имеется 4 основных таблицы. А значит форм будет 8. Но при компиляции стандартно запустится первая форма, именно поэтому последним этапом в создании базы данных является создание главной формы, о которой многократно говорилось в работе.

Рисунок 18. Главная форма.

Она нужна для ориентирования в формах (рисунок 18). То есть девятой формой мы создаем Главную форму. Для того чтобы запуск программы начинался с нее, заходим в настройки самого проекта и меняем номер таблицы в меню Main Form вкладки Forms. Девятая форма представляет собой просто окно с, в данном случае, 4 кнопками, нажимая на которые пользователь будет переходить на нужные таблицы. Код для каждой кнопки прост «Form(номер формы).show;». И, соответственно, на каждой форме, на которую идет ссылка, мы заранее делали кнопку «В главное меню», код которой такой же простой, только в номере ссылки будет стоять девятая - главная форма, а после этого прописана команда «close;».

ЗАКЛЮЧЕНИЕ

По итогам выполненной работе можно заключить, что создание простой, но работающей базы данных не столь сложный процесс. Обладая базовыми знаниями по работе в Microsoft Office Access и Borland Delphi 7, можно создать такую базу данных, что и было целью данной работы. В данной курсовой работе был представлен один из способов создания базы данных. Следуя задачам, в первую очередь была проанализирована область бизнес процессов в среде Bpwin, в соответствии с которой были созданы диаграммы в нотациях IDF0, DFD. После чего была разработана ER- диаграмма, по которой созданы три основных таблицы и одна вспомогательная. Каждая таблица имеет первичные ключи и связи друг с другом через индексы. Так же в данной работе представлены возможные sql запросы типа inner join.

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

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