рефераты конспекты курсовые дипломные лекции шпоры

Реферат Курсовая Конспект

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

Описание предметной области - раздел Программирование, Разработка базы данных «Склад магазина оптовой продажи» Описание Предметной Области. Один Из Видов Деятельности Любой Коммерческой Фи...

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

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

Склад принимает и складирует готовую продукцию, которая сопровождается накладной. Накладная может выступать как приходным, так и расходным товарным документом, она должна выписываться материально ответственным лицом при оформлении отпуска товаров со склада либо при принятии товаров. Она состоит из двух частей: общей (в которую входят номер накладной, наименование поставщика и дата сдачи продукции на склад) и спецификации (в нее входят наименования и количество передаваемой продукции). 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, который свою очередь содержит

Разработка запросов
Разработка запросов. Для соединения формы с таблицами использовался объект приложения Delphi, ADOConnections, который помещаю в DataModule. ADOConnections подключается к базе данных. Поставщ

Библиографический список
Библиографический список. Бабаева Ю.А. Бухгалтерский учет. – М.: Юнити, 2002. – 237с. 2. Бородин В.А. Бухгалтерский учёт: Учебник для вузов. – 3-е изд перераб. и доп. – М.: ЮНИТИ–ДАНА, 2004. – 528с

Хотите получать на электронную почту самые свежие новости?
Education Insider Sample
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Реклама
Соответствующий теме материал
  • Похожее
  • Популярное
  • Облако тегов
  • Здесь
  • Временно
  • Пусто
Теги