Содержание
Введение3
1. Анализ предметной области5
1.1. Описание предметной области и функции решаемых задач5
1.2. Ограничения предметной области10
2. Описание входных документов и сообщений.11
3. Описание выходных документов и сообщений12
4. Описание запросов к базе данных13
5. Выбор и описание используемой СУБД17
6. Построение информационно-логической модели.18
7. Создание базы данных20
7.1. Пользовательские формы25
7.2. Создание отчетов25
Вывод28
Литература30
Выдержка из текста работы
Содержание Введение….… ….1 Этапы разработки Базы данных… …1.1 Описание предметной области… ………….… …1.2 Разработка концептуальной модели базы данных…….….… 1.3 Разработка логической модели базы данных….… 1.4 Физическое проектирование модель….….12 2 проектирование приложений… 2.1 Обоснование выбора среды разработки приложения… 17 2.2 Разработка форм ввода вывода… 2.3 Схема взаимодействия по данным….… … 2.4 Разработка запросов….23 Заключение… 26 Библиографический список….… 27 ПРИЛОЖЕНИЕ А – Исходный текст программного продукта… 28 ПРИЛОЖЕНИЕ Б – Схема взаимодействия по данным……… ……… 38 ПРИЛОЖЕНИЕ В – Руководство пользователя… ………….…39 ВВЕДЕНИЕ База данных является важнейшей составной частью информационных систем, которые предназначены для хранения и обработки информации.
Изначально такие системы существовали в письменном виде. Для этого использовались различные картотеки, папки, журналы, библиотечные каталоги.
Развитие информационных технологий дало возможность для создания и широкого использования автоматизированных информационных систем. Информационные системы разрабатываются для обслуживания различных бизнес-систем, систем управления экономическими и техническими объектами, модельных комплексов для научных исследований, систем автоматизации проектирования и производства, всех типов тренажеров и обучения.
Современные информационные системы основаны на концепции интеграции данных, характеризующейся большими объектами архивных данных, сложной организацией, необходимостью удовлетворения различных потребностей множества пользователей. Системы управления данными были созданы для управления этими данными и обеспечения эффективного доступа к ним. Актуальность темы заключается в том, что использование баз данных на компьютере дешевле, чем хранение документов в бумажном виде, и при правильном подходе база данных может обеспечить высокую надежность хранения, скорость обработки и передачи информации.
Целью курсового проекта является создание базы данных «Склад оптового магазина». В процессе разработки базы данных «Склад магазина оптовой продажи» необходимо решить следующие задачи: изучение предметной области, учёт поступления товаров, учёт отпуска товаров, формирование перечня товаров имеющегося в складских помещениях, ценовая информация о товарах.
Объектом исследования являются среды Access и Delphi, с их помощью будет реализована база данных. Объектом исследования является возможность внедрения базы данных «Склад оптовых магазинов» в Access и Delphi. В качестве теоретической основы для курсового проекта использованы труды следующих авторов: В.А. Бородина, А.Д. Хоменко, А.Г. Фёдорова, А.В. Фёдорова, а также ряд других источников. Курсовой проект или его элементы могут быть интересны предпринимателям, занимающимся коммерческой деятельностью. 1
Этапы разработки Базы данных
1.1 Описание предметной области
Одним из направлений деятельности любой коммерческой компании является организация учета имеющейся на складе продукции.
На складе храниться товар различного типа. Склад в первую очередь занимается обработкой материалов и информационных потоков. Первые представлены движением товаров от поставщиков на склад или со склада покупателям, а информационные потоки представлены документацией, необходимой для этих операций.
На складе осуществляется прием и хранение готовой продукции, к которой прилагается накладная. Накладная может выступать как входящий, так и исходящий документ, она должна быть оформлена финансово ответственным лицом при оформлении выпуска товара со склада или приема товара. Она состоит из двух частей: общей (в которую входят номер накладной, наименование поставщика и дата сдачи продукции на склад) и спецификации (в нее входят наименования и количество передаваемой продукции). 1.2 Концептуальная модель и её описание При проектировании программ выясняются запросы и пожелания клиента и определяется возможный подход к решению задачи.
Задача анализируется. На основе этого анализа конкретная модель реализуется в конкретной программной среде. Результаты каждого этапа проектирования используются в качестве исходного материала для следующего этапа.
Проанализирована текущая организация предприятия, определены проблемы, требующие решения, определены объекты и взаимосвязи между ними, составлен «эскиз» организации действующего предприятия, разработана модель с учетом специфики условий его функционирования. База данных ориентирована на конкретную тематическую область, например: учет товарной продукции, и организована на основе определенного подмножества данных. Возможности базы данных полезны в областях, связанных с долгосрочным управлением информацией, таких как электронные библиотеки и хранилища данных.
Предварительное планирование, подготовка данных, последовательность создания информационной модели. Прежде всего, при проектировании системы обработки данных необходимо решить вопрос: «Как организовать данные?». Помочь понять организацию данных, призвана информационная модель. Процесс создания информационной модели начинается с определения концептуальных требований ряда пользователей. Концептуальные требования могут определяться и для некоторых задач (приложений), которые в ближайшее время реализовывать не планируется.
Это может немного усложнить работу, но поможет полностью учесть все нюансы функциональности, необходимой для разрабатываемой системы, и снизить вероятность переделок в будущем. Индивидуальные пользовательские требования должны быть представлены в едином «сводном виде». Последнее называют концептуальной моделью. Объект — это абстракция множества объектов реального мира, которые имеют одинаковые характеристики и законы поведения.
Объект — типичный неопределенный экземпляр такого множества. Объекты объединяются в классы по общим характеристикам. Например, в предложении «Белый дом — это здание», «Белый дом» представляет объект, а «здание» представляет собой класс. Классы обозначаются абстрактными существительными. Класс — это набор реальных объектов, связанных общей структурой и поведением. Автоматизированная система обработки данных основана на использовании конкретной модели данных или информационной модели.
Модель данных отражает взаимосвязи между объектами. Процесс создания информационной модели начинается с определения концептуальных требований ряда пользователей. Концептуальные требования могут определяться и для некоторых задач (приложений), которые в ближайшее время реализовывать не планируется. Это может немного усложнить работу, однако поможет полностью учесть все нюансы функциональности, необходимой для разрабатываемой системы, и снизить вероятность ее переделки в будущем.
Индивидуальные требования пользователей объединены в единое «общее представление». Последнее называют концептуальной моделью. Концептуальная модель представляет объекты и их отношения без указания того, как они физически хранятся. Таким образом, она является, по существу, моделью предметной области. При разработке концептуальной модели все усилия разработчика должны быть направлены в первую очередь на структурирование данных и определение взаимосвязей между ними без учета характеристик реализации и вопросов эффективности обработки.
Дизайн концептуальной модели основан на анализе решаемых на данном предприятии задач по обработке данных. Концептуальная модель включает описания объектов и их взаимосвязей, которые представляют интерес в рассматриваемой предметной области и которые идентифицируются в результате анализа данных. Для данной предметной области можно спроектировать следующую концептуальную модель (см. рисунок 1.1). Концептуальная модель базы данных состоит из восьми объектов. Объект «Накладная», хранит реквизиты документов движения, так же будет хранить информацию о типах хозяйственных операций: приход или расход.
Объект «Накладная строки», содержит информацию о движении товаров, что и в каком количестве и по какой цене пришло или ушло. Объекты «Накладная» и «Накладная строки» связанны между собой по типу одна ко многим (см. рисунок 1.1). Объект «Клиенты», содержит контактные данные о клиентах, которые являются поставщиками и заказчиками, такие как фамилия, адрес телефон, и другая информация. «Ответственные лица», обобщает информацию о сотрудниках склада несущих материальную ответственность за хозяйственные операции с товарами.
Рисунок 1.1 – Концептуальная модель Объект модели «Товары», как следует из названия, будет содержать список товаров, которые будут использоваться в хозяйственных операциях на складе. Объект «Остатки» позволяет всегда быть в курсе имеющихся товаров на складе. Объект «Единицы измерения» позволяет измерить товары в количественном эквиваленте.
Объект «Цены товара» цены товаров постоянно меняются, поэтому данный объект хранит информацию о продажных ценах товаров на определённый день, месяц, год. Концептуальная модель транслируется затем в модель данных, совместимую с выбранной системой управления базами данных (далее СУБД). Возможно, что отраженные в концептуальной модели взаимосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения концептуальной модели.
Версия концептуальной модели, которая может быть обеспечена конкретной СУБД, называется логической моделью. 1.3 Логическая модель Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среде хранения. Логическая модель данных может быть реляционной, иерархической или сетевой. Пользователям выделяются подмножества этой логической модели, называемые внешними моделями, отражающие их представления о предметной области.
Внешняя модель соответствует представлениям, которые пользователи получают на основе логической модели, в то время как концептуальные требования отражают представления, которые пользователи первоначально желали иметь и которые легли в основу разработки концептуальной модели. Логическая модель отображается в физическую память, такую, как диск, лента или какой-либо другой носитель информации.
Рисунок 1.2 – Логическая модель Как видно из логической схемы (см. рисунок 1.2), база данных будет состоять из следующих восьми сущностей: 1) накладная – в поле «номер» заносится номер накладной, поле «приход» используется для указания типа накладной (приход или расход). Поле «клиент» указывает на клиента (поставщик или потребитель). «Дата» – дата заказа. Поле «Комментарий» может использоваться для информации дополнительного рода, например для указания ссылки, на дополнительные виды сопроводительных документов, или другую какую-нибудь полезную информацию, поле является не обязательным.
Товар заноситься в склад лишь в том случае, если указана дата обработки поле «Обработана». 2) накладные строки – если прочитать название полей (см. рисунок 1.2), то станет ясно, что в таблице храниться информация о товарах «привязанных» по коду к какой-либо накладной. 3) клиенты – в данном случае под видом лица понимается поставщик или потребитель, в случае если клиент является поставщиком тогда ставиться галочка в поле «Вид лица». 4) ответственные – «ответственные лица», эта таблица содержит информацию о сотрудниках, на которых возлагается материальная ответственность за ведение хозяйственных операций с товарами на складе. 5) товары – содержит список товаров, использующийся в различных операциях. 6) единицы измерения – в поле «Название» пишется полное название единицы измерения, например: «килограммы», а поле «СокрНазвание» его сокращённое название: «кг», это сделано для удобства и экономии места на формах ввода/вывода. 7) цены товара – Таблица хранит информацию обо всех ценах для товаров, которые были назначены на определённую дату. 8) остатки – содержится информация о товарах имеющихся в складских помещениях. 1.4 Физическая модель Физическая модель, определяющая размещение данных, методы доступа и технику индексирования, называется внутренней моделью системы. Внешние модели никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным.
Это положение отражает первый уровень независимости данных.
С другой стороны, если концептуальная модель способна учитывать расширение требований к системе в будущем, то вносимые в нее изменения не должны оказывать влияния на существующие внешние модели.
Это – второй уровень независимости данных. Построение логической модели обусловлено требованиями используемой СУБД. Все актуальные требования предметной области и адекватные им «скрытые» требования на стадии проектирования должны найти свое отражение в концептуальной модели.
Конечно, нельзя предусмотреть все возможные варианты использования и изменения базы данных. Но в большинстве предметных областей такие основные данные, как объекты и их взаимосвязи, относительно стабильны. Меняются только информационные требования, то есть способы использования данных для получения информации. Степень независимости данных определяется тщательностью проектирования базы данных. Всесторонний анализ объектов предметной области и их взаимосвязей минимизирует влияние изменения требований к данным в одной программе на другие программы.
Описание таблиц: «Накладная», регистрирует приходные и расходные операции (см. таблицу 1.1.) Таблица 1.1–Накладная № Название Тип, доп инф. 1 Накладная Счетчик, первичный ключ 2 Номер Текстовый (50) 3 Приход Логический 4 Клиент Числовой 5 Дата Дата/время 6 Ответственный Числовой 7 Комментарий Текстовый (250) 8 Обработана Дата/время Для регистрации типа накладной используется логическое поле №3 (см.таблицу 1.1). В поле №6 будет ссылаться на таблицу «ОТВЕТСТВЕННЫЕ» по числовому значению.
Поля №5 и №8 имеют тип дата/время. «Накладные Строки», используется для ввода спецификации накладной (см. таблицу 1.2), т.е. информации касающееся самого товара, его количества и покупной или продажной цены. Таблица 1.2–Накладные строки № Название Тип, доп инф. 1 НакладнаяСтроки Счетчик, первичный ключ 4 Количество Числовой 5 Единица измерения Числовой 6 Цена Денежный 7 Сумма Денежный Все поля таблицы за исключением цены и суммы, являются числовыми которые, по их значениям ссылаются на другие таблицы базы данных (далее БД). Поле №6 равно цене ед. товара, а поле №7 равно поле №4 умноженное на №7. «Клиенты», содержит информацию о поставщиках и заказчиках (см. таблицу 1.3) Таблица 1.3–Клиенты № Название Тип, доп инф. 1 Клиент Счетчик, первичный ключ 2 Вид лица Логический 3 Наименование общества Текстовый (10) 4 Полное название орг Текстовый (150) 5 ФИО Текстовый (50) 6 Адрес Текстовый (150) 7 Телефон Числовой (20) В поле №2 имеющее тип логический отличает значением «истина» поставщика от клиента. «Ответственные лица», через ключевое поле №1, эта таблица связывается с таблицей «накладные» (см. таблицу 1.4). Таблица 1.4–Ответственные лица № Название Тип, доп инф. 1 Код ответственного Счетчик, первичный ключ 2 ФИО Текстовый (50) 3 Должность Текстовый (50) 4 Адрес Текстовый (50) 5 Телефон Числовой (20) «Товары» первичный ключ связывает таблицу с остальными (см. таблицу 1.5). Таблица 1.5–Товары № Название Тип, доп инф. 1 Код товара Счетчик, первичный ключ 2 Название Текстовый (100) 3 Тип Текстовый (50) Таблица «Единицы Измерения» (см. таблицу 1.6) Таблица 1.6–Единицы Измерения № Название Тип, доп инф. 1 ЕдиницаИзмерения Счетчик, первичный ключ 2 Название Текстовый (20) 3 СокрНазвание Текстовый (6) «Цены товара», Эта таблица предназначена для формирования продажной цены товаров (см. таблицу 1.7). Таблица 1.7–Цены товара № Название Тип, доп инф. 1 ЦенаТовара Счетчик, первичный ключ 2 Товар Числовой 3 Дата Дата/время 4 Цена Денежный «Остатки», здесь используются два первичных ключа которые поля №1 и №2 вместе они создают уникальное значение для записи (см. таблицу 1.8). Таблица 1.8 – Остатки № Название Тип, доп инф. 1 Товар Числовой, первичный ключ 2 Накладная Числовой, первичный ключ 3 Количество Числовой 4 ЕдиницыИзмерения Числовой Сделаем наиболее важные выводы по первым трем этапам проектирования БД. В настоящее время любая деятельность подвергается планированию, без плана нет организации, если нет организации в деятельности, то успех маловероятен.
Проектирование БД аналогично созданию плана или «последовательности шагов» на пути к реализации программы.
Проектирование БД также позволяет выявить ошибки, допущенные на предыдущих этапах разработки. Что позволяет вернуться назад и внести изменения в схемы ещё до создания программной платформы.
Бес проектирования БД, в процессе разработки могу возникнуть неточности или ошибки например в логической схеме, что с большой вероятностью может привести к провалу проекта. 2 проектирование приложений 2.1 Выбор среды программирования Delphi – это попытка фирмы borland объединить лучшее, что было создано на тему визуального программирования, в единый продукт.
В Delphi мы имеем: среду для создания программ, напоминающую среду Visual Basic и включающую в себя средство для наглядного создания программ, и редактор для написания кода. В Delphi практически все создаваемые программы являются объектно-ориентированными.
В качестве языка был выбран Object Pascal – объектно–ориентированное расширение языка третьего поколения Раsса1. Почему Pascal, а не язык C++, ставший практически индустриальным стандартом? Все дело в том, что на язык Pascal нет стандарта.
Точнее, есть ANSI-стандарт, принятый в начале 80-х годов.
Отсутствие стандарта на язык позволяет разработчикам компиляторов вносить в него необходимые расширения, что недопустимо, скажем, в С/С++. Если первые версии turbo Pascal ещё как-то следовали спецификации, предложенной Никлаусом Виртом, то далее стала заметна не только тенденция привязки языка к компьютеру, но и стремление сделать его гибким и удобным инструментом, которому «тесно» в рамках каких-либо стандартов.
С помощью Delphi можно создавать компоненты ActiveX без использования Microsoft IDL, расширять возможности web-сервера, практически ничего не зная об HTML, XML или ASP. Можно создавать Интернет- и intranet-приложения, используя для доступа к данным Borland DataBase Engine, ODBC-драйверы или Microsoft ADO. Мощность и гибкость Delphi при работе с базами данных основана на низкоуровневом ядре — процессоре баз данных Borland Database Engine (BDE). Его интерфейс с прикладными программами называется Integrated Database Application Programming Interface (IDAPI). В принципе.
BDE позволяет осуществлять доступ к данным как с использованием традиционного record- ориентированного (навигационного) подхода, так и с использованием set- ориентированного подхода, используемого в SQL-серверах баз данных.
Кроме BDE, Delphi позволяет осуществлять доступ к базам данных, используя технологию Open DataBase Connectivity (ODBC) фирмы Microsoft. Все инструментальные средства баз данных Borland — Paradox, dBase, Database Desktop — используют BDE. Все особенности, имеющиеся в Paradox или dBase, «наследуются» BDE, и поэтому этими же особенностями обладает и Delphi.
Одним из преимуществ Delphi является то, что он поддерживает все SQL-БД, доступ к которым осуществляется через Borland Database Engine, ADO или драйверы InterBase. Через Borland SQL Links BDE так же возможен доступ к Oracle, Sybase, Informix, MS SQL Server, DB2 и InterBase Access – это, прежде всего, система управления базами данных. Как и другие продукты этой категории, она предназначена для хранения и поиска данных, представления информации в удобном виде и автоматизации часто повторяющихся операций.
С помощью Access можно разрабатывать простые и удобные формы ввода данных, а также осуществлять обработку данных и выдачу сложных отчетов. Access – мощное приложение Windows, впервые производительность СУБД органично сочетается с теми удобствами, которые имеются в распоряжении пользователей Microsoft Windows. Поскольку оба эти продукта, детища компании Microsoft, они прекрасно взаимодействуют между собой. С помощью объектов OLE (Object Linking and Embedding – связывание и внедрение объектов) в Windows и компонентах Microsoft Office (Excel, Word, PowerPoint и Outlook) можно превратить Access в настоящую операционную среду баз данных.
С помощью новых расширений для Internet можно создавать формы, которые будут напрямую взаимодействовать с данными из World Wide Web, и транслировать их в представление на языке HTML, обеспечивающее работу с такими продуктами, как Internet Explorer и Netscape Navigator. Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет использовать одновременно несколько таблиц базы данных.
Таблицу Access можно связать с данными, хранящимися на большой ЭВМ или на сервере. Система Access – это набор инструментов конечного пользователя для управления базами данных. В ее состав входят конструкторы таблиц, форм, запросов и отчетов. Эту систему можно рассматривать и как среду разработки приложений. Используя макросы или модули для автоматизации решения задач, можно создавать ориентированные на пользователя приложения такими же мощными, как и приложения, написанные непосредственно на языках программирования.
В данном курсовом проекте Access будет использоваться как место хранения данных, т.е. как БД, а средства Delphi будет использоваться как средство доступа к хранящимся данным, т.е. как СУБД. 2.2 Формы ввода-вывода информации Программа, будет начинать работу с вывода главной формы, т.е. на котором будет «панель навигации» по другим формам (см. рисунок 2.1). Рисунок 2.1 – Склад магазина При наведении курсора на «Документы» выпадает меню с выбором документов, «Накладная», «Прайс-лист» и «Склад». При наведении курсора мыши на «Списки» выпадает список со следующим выбором форм ввода: «Единицы измерения», «Товары», «Ответственные лица», «Клиенты». Справа от «Списков» кнопка «Выход из программы» при её нажатии приложение закроется.
При наведении мышки на слово «Списки» (см. рисунок 2.1) открывается субменю, которое предоставляет возможность выбрать одну из форм для ввода данных в БД. Например, при выборе «Поставщики» в субменю «Клиенты», в «Списках». Откроется форма ввода данных о поставщиках (см. исунок 2.2–Поставщики В поле «Наименование общества» вводиться вид общества, например: «ООО» (Общество с ограниченной ответственностью), программа предназначена для ввода в данное поле абривиатур, это экономит время пользователю и экономит место на форме вывода данных (отчёте). В поле «Название организации» вводиться название фирмы поставщика.
В поле «ФИО» вводиться фамилия руководителя фирмы.
В поле «Адрес» вводиться юридический адрес фирмы. При нажатии кнопки «Отчёт» (см. рисунок) 2.2 программа выводит отчёт обо всех поставщиках товарной продукции (см. рисунок 2.3). При наведении курсора мыши на «Документы» откроется субменю (см. р2.3
Схема взаимодействия по данным
Из схемы взаимодействия по данным видно (см. приложение В), что она состоит из восьми форм ввода данных, которые связаны с файлом .mdb, который свою очередь содержит в себе восемь таблиц: накладная, накладные строки, клиенты, ответственные, товары, единицы измерения, цены товара, остатки.
В каждую таблицу вводяться данные через формы ввода: orgnz, FClients, otvetstvenie, edizm, pricelist, Tovar, rashod, prihod. Многочисленные связи в схеме (см. приложение В), позволяют отследить взаимодействия форм и таблиц в базе данных. Так же используются формы вывода данных: otchprih, otchrash, otchTov, otchPris, otchediz, otchost, otchediz, otchotv, otchclts, otchorg. 2.4
Разработка запросов
Для соединения формы с таблицами использовался объект приложения Delphi, ADOConnections, который помещаю в DataModule.
ADOConnections подключается к базе данных. Поставщики данных (Provider) перечислены все доступные ADO драйверы доступа к базам данных: для Access используется драйвер Microsoft Jet OLE DB Provider. Такой драйвер обязательно устанавливается на машину вместе с MS Office, а в последних версиях Windows он устанавливается всегда по умолчанию. В новом окне с заголовком Form1.ADOTable1.ConnectionString нужно выбрать пункт Use Connection String затем, Build в вновь открывшемся окне указывается путь к своей базе данных.
Как только произошёл выбор нужной базы данных, необходимо проверить подключение, для этого нажимается кнопка «Проверить подключение» (Test Connection), чтобы протестировать соединение. Следующий шаг, на форму устанавливается компонент DataSource с вкладки Data Access палитры компонентов. Теперь этому компоненту указывается таблица отображения: свойство DataSet–ADOTable1, который связан с таблицей.
Все приготовления готовы, далее нужно приступить к реальному отображению данных. Самый простой способ отобразить таблицу – установить компонент DBGrid (Вкладка Data Controls). Этот компонент – сетка, которая может отображать данные в виде таблицы. DBGrid (см. рисунок 2.6). Так же есть другой способ отображения данных, с помощью компонента Delphi DBEdit, это так называемое поле (см. рисунок 2.2). DBEdit позволяет отображать конкретное поле из таблицы, эти два способа будут использованы в курсовом проекте.
Чтобы отобразить форму ввода для «Прайс–листа» (см. рисунок 2.6), использовался следующий запрос: SELECT ЦеныТовара. ЦенаТовара, ЦеныТовара. Товар, Товары. Название, ЦеныТовара. Дата, ЦеныТовара. Цен FROM ЦеныТовара, Товары WHERE ЦеныТовара. Товар=Товары.[Код товара] ORDER BY Товары. Название; Этот запрос был реализован в СУБД Access, он подключён через компонент Delphi ADOTeble, и компонент DataSet, данные выведены на форму с помощью DBGrid. Запрос основан на двух таблицах: «ЦеныТовара», «Товары» которые объединены через «Код товара» и упорядочены по текстовому полю таблицы «Товары». Раздел реквизитов формы «Накладная приход» основана на следующем запросе, созданном в СУБД Access: SELECT Накладные. Накладная, Накладные. Номер, Накладные. Приход, Накладные.
Клиент, Накладные. Дата, Накладные. Ответственный, Накладные. Комментарий, Накладные. Обработана FROM Накладные WHERE (((Накладные. Приход)=True) AND ((Накладные. Обработана) Is Null)) ORDER BY Накладные. Дата; Подключение этого запроса к выводу в форму представления данных осуществляется, так же как и для первого примера (Прайс-лист). Он выводит, как можно увидеть из запроса, только те данные из таблицы «Накладные», которые удовлетворяют условиям, перечисленным в разделе WHERE, т.е. значение «Приход» должно быть истинным и значение поля «Обработана» должно равняться значению Null. Это было сделано для того, чтобы человек вводящий данные мог работать только с необработанными накладными, т.е. с теми заказами, которые были сделаны, но не пришли ещё на склад (ожидаемыми поставками). Работа с другими формами основана на тех же принципах, которые были перечислены выше, отличие заключается лишь в выборке данных из таблиц с помощью запросов, например для разработки отчёта «Список поставщиков» (см. рисунок 2.3) был использован следующем запрос: SELECT Клиенты. Клиент, Клиенты.[Вид лица], Клиенты.[Наименование общества], Клиенты.[Название орг], Клиенты. ФИО, Клиенты. Адрес, Клиенты. Телефон FROM Клиенты WHERE (((Клиенты.[Вид лица])=True)) ORDER BY Клиенты.[Название орг];
Заключение
В рамках подготовки настоящего курсового проекта были рассмотрены следующие вопросы: бухгалтерский учёт складских операций, теоретические основы в проектировании базы данных, проектирование базы данных складского учёта, создание системы управления базой данных.
С помощью спроектированной системы управления базой данных можно осуществлять ввод справочной информации, такой как типы единиц измерения, сведения о новых клиентах, поставщиках и материально ответственных лицах, а также непосредственно товаров участвующих в хозяйственных операциях и их цены. Система управления базой данных также позволяет создавать документы прихода и расхода товаров, тем самым осуществлять контроль за его движением, хранить последнюю информацию о товарах, имеющихся на складе и их количестве.
База данных хранит информацию обо всех произведённых хозяйственных операциях с товарами, что позволит в будущем разработать сложную систему отчётов, которые помогут осуществлять некоторые функции бухгалтерского учёта, такие как: контрольную, информационную и аналитическую.
С учётом современной ценовой динамики база данных позволяет хранить все используемые цены товаров.
На основе достигнутых результатов можно сформулировать рекомендации по улучшению программы: — использование web-технологий для доступа к данным через Интернет; — создание пользователей с определёнными правами доступа к данным; — разработка дополнительных форм ввода/вывода информации о накладных. — разработка новых таблиц базы данных для фиксирования мест расположения товарной продукции на складе или складах.
Библиографический список
Бабаева Ю.А. Бухгалтерский учет. – М.: Юнити, 2002. – 237с. 2. Бородин В.А. Бухгалтерский учёт: Учебник для вузов. – 3-е изд перераб. и доп. – М.: ЮНИТИ–ДАНА, 2004. – 528с. 3. Фёдоров А.В. ADO в Delphi. – Пер. с англ. – СПб.: БХВ–Петербург, 2002. – 816с. 4. Фёдоров А.Г. Создание Windows–приложений в среде Delphi. – М.: ТОО «Компьютер Пресс», 1995. – 287с. 5. Хоменко А.Д. Delphi 7. – СПб.: БХВ–Петербург, 2003. – 1216с. 6. Хоменко А.Д. Основы современных компьютерных технологий. – М.: ТОО «Компьютер Пресс», 2000г. – 467с. исунок 2.4).
