Разработка базы данных "Магазин"

Тип работы:
Курсовая
Предмет:
Программирование


Узнать стоимость

Детальная информация о работе

Выдержка из работы

Министерство образования и науки Российской Федерации

ФГБОУ ВПО

«Дагестанский государственный Технический Университет»

Филиал в г. Дербент

Курсовая работа

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

на тему:

Разработка базы данных "Магазин"

Выполнил: студентка 3-го курса

Специальности ПОВТ и АС,

051 группы Мятова В. Г.

Проверил: ст. преподаватель

Джумалиева Е.Р.

Дербент 2013

Аннотация

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

Курсовая работа содержит:

Листов печатного текста — _____

Рисунков — 9

Таблиц — 2

Библиографических источников — 8

Содержание

  • Аннотация
  • Введение
  • Техническое задание
  • 1. Теоретическая часть
  • 1.1 Данные и ЭВМ
  • 1.2 Концепция баз данных
  • 1.3 Модели данных
  • 1.4 Описание этапов проектирования
  • 2. Практическая часть
  • 2.1 Разработка инфологической модели
  • 2.2 Разработка базы данных для хранения и обработки информации
  • 2.3 Разработка программного приложения
  • Заключение
  • Список использованной литературы
  • Приложение 1
  • Приложение 2

Введение

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

База данных на сегодняшний день — это самый распространенный «повод» для написания программ. Все современные языки программирования содержат в себе встроенные возможности для быстрого и удобного создания СУБД (лидерами, на мой взгляд, сейчас является Delphi 5 и С++ Builder 5).

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

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

база программное приложение магазин

Техническое задание

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

1. Теоретическая часть

1.1 Данные и ЭВМ

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

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

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

1.2 Концепция баз данных

Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых «Системы управления базами данных» (СУБД).

Основная особенность СУБД — это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банками данных, а затем «Базами данных» (БД).

1.3 Модели данных

Имеются две основные модели данных: инфологическая модель и даталогическая модель.

Инфологическая модель отображает реальный мир (предметную область) в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель «сущность-связь» и т. д. Наиболее популярной из них оказалась модель «сущность-связь». Инфологическая модель должна быть отображена в компьютеро-ориентированную даталогическую модель, «понятную» СУБД. В процессе развития теории и практического использования баз данных, а также средств вычислительной техники создавались СУБД, поддерживающие различные даталогические модели. Сначала стали использовать иерархические даталогические модели. Простота организации, наличие заранее заданных связей между сущностями, сходство с физическими моделями данных позволяли добиваться приемлемой производительности иерархических СУБД на медленных ЭВМ с весьма ограниченными объемами памяти. Но, если данные не имели древовидной структуры, то возникала масса сложностей при построении иерархической модели и желании добиться нужной производительности.

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

1.4 Описание этапов проектирования

1. Инфологическая модель БД.

Этапом инфологической модели является этап проектирования БД на котором составляется инфологическая модель и схемы взаимосвязи можно определить, что данный этап является первым.

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

Требования к инфологической модели:

адекватное отображение предметной области;

непротиворечивость;

должна отражать взгляды и потребности всех пользователей системы;

однозначная трактовка моделей;

модель должна быть конечной;

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

должна обладать свойствами композиции и декомпозиции (укреплять базу данных или расщеплять);

должна быть легко реализуемой на ЭВМ;

должна быть независимой от оборудования и языков организации базы данных на ЭВМ.

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

Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).

Сущность — любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т. д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром — Москва.

Атрибут — поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т. д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности.

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

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

2. Даталогическая модель БД.

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

3. Физическая модель БД.

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

2. Практическая часть

2.1 Разработка инфологической модели

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

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

На рис. 1 представлена полученная инфологическая модель.

Задание: склад магазинов.

База данных состоит из двух таблиц.

1. Таблица «Склад» — место нахождение товаров на складе.

2. Таблица «Товары» — качественные и количественные характеристики товаров.

Рис. 1: Инфологическая модель

2.2 Разработка базы данных для хранения и обработки информации

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

Схемы данных для хранения информации о магазинах

Схема данных для хранения информации о складе:

Таблица 1:

Наименование

Название

Тип

Размерность

1

N_Zd

Номер здания

Числовой

2

N_St

Номер стеллажа

Числовой

3

N_P

Номер полки

Числовой

4

Kod

Код товара

Числовой

Схема данных для хранения информации о товарах:

Таблица 2:

Наименование

Название

Тип

Размерность

1

Kod

Код товара

Числовой

2

Cena

Цена товара

Числовой

3

Kol

Количество (шт.)

Числовой

4

Naim

Наименование

Символьный

25

5

Kach

Качество товара

Символьный

8

Рассмотрим связи таблиц.

1. Сложная связь, которая предназначена для определения характеристик товара. Со стороны таблицы «склад» эта связь является множественной, так как один и тот же товар может находиться в разных местах на складе. Со стороны таблицы, товары — это связь является множественной, так как на одной полке — минимальной единицы указано местоположение — может находиться более одного наименования товаров. С точки зрения программной реализации данной связи является очень сложной.

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

Прежде, чем начать строить приложения, работающие с базами данных, надо иметь сами базы данных. Вместе с BDE и Borland C++Builder поставляется программа Database Desktop, которая позволяет создавать таблицы баз данных некоторых СУБД, задавать и изменять их структуру. Для каждого поля создаваемой таблицы, прежде всего, указывается имя (Field Name) — идентификатор поля. Он может включать до 25 символов и не может начинаться с пробела (но внутри пробелы допускаются). Затем надо выбрать тип (Type) данных этого поля. Для этого перейдем в раздел Type поля и щелкнем правой кнопкой мыши. В появившемся списке доступных типов, из которого мы можем выбрать необходимый.

Разные СУБД по-разному организуют и хранят базы данных. СУБД Paradox используют для каждой таблицы отдельный файл. В этом случае база данных — это каталог, в котором хранятся файлы таблиц. Для создания такого каталога — базы данных необходимо запустить инструмент BDE Administrator (Borland Database Engine) из меню Пуск| Программы| C++Builder. В левой половине окна расположен список существующих баз данных. Создадим новые базы данных. Для этого с главного меню зададим команду Object | New. На данную команду BDE выведет окно. Переименовав название STANDART на BOLNIE, и задав путь, где располагаются таблицы базы данных (Path — обычно это каталог Database DesktopWorkdir) закончим работу с BDE. Итак, мы можем создавать таблицы для базы данных Товаров. Загрузим инструментарий Database Desktop. Через главное меню составим команду File | New | Table. На запрос системы выберем платформу таблиц СУБД Paradox v.7. В открывшееся окно введем структуру таблицы Sklad. db.

Рис. 2: Ввод данных в таблицу

Введем данные сначала в таблицу. Для этих целей можно использовать горячую кнопку «Open Table». В открывшуюся таблицу можно внести данные о наименованиях. Для этих целей на панели инструментов расположена кнопка редактирования (Edit Data), «нажатие» которой добавляет новую запись с данными по умолчанию, готовую для редактирования. Введем наименования товаров. После этого закроем окно с таблицей.

Аналогичными действиями создадим таблицу Tovar. db. В этой таблице первичным ключом установим код товара (поле Tovar).

Выберем пункт меню Table|Restructure, позволяющий изменять свойства таблицы, при этом окно аналогично окну создания таблицы. Выберем в спадающем списке пункт Secondary Indexes. Нажав кнопку «Define.» откроем окно, в котором слева расположены поля таблицы, а справа пустое окно, в которое заносятся поля, по которым создается индекс. Вторичными индексами обозначим s1-Cena, s2-Kol, s3-Naim, s4-Kach.

Далее вводим данные в таблицу.

Рис. 3: Ввод данных в таблицу

2.3 Разработка программного приложения

Язык SQL (Structured Query Language) — язык структурированных запросов) был создан Microsoft в конце 70-ых годов и получил через некоторое время широкое распространение. Он позволяет формировать весьма сложные запросы к базам данных. Запрос - это вопрос к базе данных, возвращающий запись или множество записей, удовлетворяющих вопросу.

C++Builder позволяет приложению при помощи запросов SQL использовать данные:

Таблиц PARADOX и dBase используется синтаксис локального SQL.

Локального сервера InterBase — полностью поддерживается соответствующий синтаксис.

Удаленных серверов SQL через драйверы SQL Links.

В Borland C++Builder имеется специальный компонент набора данных Query, являющийся аналогом Таblе, но позволяющий работать с SQL

1. Создание простого приложение. Подключение к форме компонентов DataSource, Query, DBGrid, причем в качестве базы данных используем таблицы созданные в лабораторной работе № 2. Выведение в сетку таблицы (DBGrid).

Откроем новое приложение (File/New/Application) Borland C++Builder, перенесём на форму компонент Query со страницы библиотеки Data Access (BDE) и установим его свойство DatabaseName равным имени созданной нами базы данных (Sklad). Поместим на форму компонент DataSource со страницы Доступ к данным (Data Access). Его свойству Name соответствует Datasource1, а свойству DataSet задайте Queryl. Поместим также на форму компонент DBGrid (Управление данными - Data Control) и в его свойстве DataSource зададим DataSourcel

Теперь наше приложение для экспериментов с языком SQL готово. Операторы SQL можем писать в свойстве SQL компонента Queryl, а чтобы увидеть результаты выполнения написанного оператора, надо будет устанавливать значение свойства Active компонента Queryl в true. Это надо будет делать после записи каждого нового оператора. В свойстве SQL запишем оператор: Select Kod as Код, N_St as Ном_стеллажа, N_P as Номер_полки, N_Zd as Номер_здания from Sklad

Установим свойство Active в true и убедимся, что все работает нормально: в DBGridI должно отобразиться содержимое таблицы Sklad. Добавив компоненту DBNavigator и установив свойство DataSource равным DataSource1 запустим на выполнение полученное приложение.

Создадим другую аналогичную цепочку, перенеся на форму компоненты Query2, DataSource2. DBGrid2, и связав ее с таблицей Tovar. db запросом в компоненте:

Select * from Tovar

в компоненте Qnery2. Установим свойство Active компонента Query2 в true и в DBGrid2 должно отобразиться содержимое таблицы Tovar. Запустим приложение и убедимся, что оно работает, причем таблицы независимы. Теперь давайте, свяжем эти таблицы. Делается это следующим образом. Изменим текст запроса в свойстве SQL вспомогательного компонента набора данных Query2 на: Select Kod as Код, Cena as Цена, Kol as Наименование, Naim as from Tovar

Рис. 4: Страница поиска

В этом запросе мы указываем условие отбора: значение поля Koд должно быть равно параметру Коd. В данном случае не надо определять этот параметр с помощью редактора параметров, вызываемого из свойства Params компонента Query2. Вместо этого в свойстве DataSource компонента Query2 надо сослаться на: DataSourcel - источник данных, связанный с таблицей Sklad. Это скажет приложению, что оно должно взять значения параметра Номер_здания из текущей записи этого источника данных. Таким образом, вспомогательная таблица, запрашиваемая в Query2, оказывается связанной с головной таблицей, запрашиваемой в Queryl

Добавив компоненты визуализации Label (свойство Caption) DBText (свойства DataSource=DataSource1, DataField = соответствуюшее поле) получим конечную форму приложении.

Рис. 5: Страница редактирования и данных

На странице «Поиск и Фильтрация» размещаем: по одному компоненту DBGrid, DBNavigator, 1 компонентов Edit, 2 компонент ComboBox и 1 компонент RadioGroup.

Для компоненты RadioGroup установлены такие свойства: Caption=Фильтрация, Items=Все, Здание, Columns=2. В событии OnClick компонента RadioGroup записываем код который будет осуществлять фильтрацию (Приложение 1).

В свойствах Items для компонента ComboBox1 (CB1) перечислены все здания. Свойству ItemIndex присвоено значение 0. Для каждой компоненты Edit размещены компоненты Label с соответствующими надписями. Для компоненты Edit1 в событии OnChange записываем соответствующий код который будет осуществлять поиск (Приложение 1). Использованные также свойства Font и Color придали странице вид. После выполнения всех указанных действий и создания программного кода на этой странице компоненты PageControl будет происходить поиск и фильтрование данных.

Для некоторых компонент в свойстве Font, Color установлены определенные цвета фоновой заливки, шрифта для большей привлекательности таблицы.

Рис. 6: Страница фильтрация и поиск

Заключение

Данная курсовая работа посвящена разработке базы данных «Магазин» для магазинов. Она заключена в автоматизации ведения учета. Такого рода программы очень распространены на сегодняшний день.

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

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

В процессе выполнения курсовой работы я получила навыки работы с программой Borland C++ Builder 6. Она актуальна в наше время, многие информатики-экономисты используют ее в своей практической работе.

Список использованной литературы

1. Диго С. М. Проектирование баз данных. М.: Финансы и статистика, 2002 г.

2. Марков А. С. Базы данных. Введение в теорию и методологию. М.: Финансы и статистика, 2002 г.

3. Мейер Д. Теория реляционных баз данных. М., 1987. 608 с., ил.

4. Тихонов А. Ф., Тихонова Л. Н. Visual FoxPro 5.0. М., 1997. 466 с.

5. Архангельский А. Я. Программирование в C++ Builder 6 — М: ЗАО «Издательство БИНОМ» 2002 г.

6. Архангельский А. Я. Интегрированная среда разработки C++ Builder 5 — М: ЗАО «Издательство БИНОМ», 2000 г.

7. Архангельский А. Я. Работа с локальными базами данных в C++ Builder 5 — М: ЗАО «Издательство БИНОМ», 2000 г.

8. Архангельский А. Я. Язык SQL в C++ Builder 5 — М: ЗАО «Издательство БИНОМ», 2000 г.

Приложение 1

Листинг программы

// ---------------------------------------------------------------------------

#include < vcl. h>

#pragma hdrstop

#include «Unit1. h»

// ---------------------------------------------------------------------------

#pragma package (smart_init)

#pragma resource «*. dfm»

TForm1 *Form1;

// ---------------------------------------------------------------------------

__fastcall TForm1: TForm1 (TComponent* Owner)

: TForm (Owner)

{

}

// ---------------------------------------------------------------------------

void __fastcall TForm1: RGFClick (TObject *Sender)

{

if (RGF-> ItemIndex==0)

Table1-> Filtered=False;

else

{Table1-> Filter="N_Zd='"+CB1->Text+"'";

Table1-> Filtered=True; }

}

// ---------------------------------------------------------------------------

void __fastcall TForm1: CB1Change (TObject *Sender)

{ if (RGF-> ItemIndex==0)

Table1-> Filtered=False;

else

{Table1-> Filter="N_Zd='"+CB1->Text+"'";

Table1-> Filtered=True; }

}

// ---------------------------------------------------------------------------

void __fastcall TForm1: Edit1Change (TObject *Sender)

{

Table2-> FindNearest (& TVarRec (Edit1-> Text), 0);

}

// ---------------------------------------------------------------------------

Приложение 2

Результат работы программы.

Рис. 1: Результат работы поиска

Рис. 2: Результат работы редактирование данных

Рис. 3: Результат работы фильтрация и поиск

ПоказатьСвернуть
Заполнить форму текущей работой