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

Содержание

Введение

1. Общие сведения об инфологическом и даталогическом проектировании

1.1 Современные СУБД для ПК

1.2 Принципы организации данных, лежащие в основе СУБД

2.Структура объекта управления

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

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

5. Связь баз данных

Заключение

Литература

Приложения

План:

1. Введение

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

2.1 Этапы проектирование БД

2.2 Современные СУБД для ПК

2.3 Обзор и сравнительная характеристика программного обеспечения, используемого при создании СУБД

2.4 Принципы организации данных лежащих в основе СУБД

2.5 Современные технологии, используемые в работе с данными

2.6 Модель данных

2.7 Связь баз данных

2.8 Даталогическая модель

2.9 Инфологическая модель

2.10 Внешний вид программы

2.11 Схема карта работы с программой

3. Текст программы

4. Список используемой литературы

Введение

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

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

1.Общие сведения об инфологическом и даталогическом проектировании

Рассмотрим вопрос о проектировании метода баз данных [1,4,7,8]. К любой базе данных возможен подход на каждом из следующих трех уровней (рис.1):

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

· на уровне концептуального представления данных (представления администратора);

· на уровне внутреннего представления данных (с позиции системного программиста) или представления реализации.

Под представлением данных понимают правила организации и кодировании данных.

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

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

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

Рис.1 Трехуровневое представление данных в концепции ANSI/SPARC.

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

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

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

Наибольший интерес для нас представляет концептуальное представление данных, связанное с развитой в 70-80-е годы ХХ века теории баз и банков данных [2, 3, 8] и направленное на унификацию данных и уменьшение избыточности при интегрировании внешних представлений в концептуальное.

Концептуальное представление основано на определенной модели данных. Этот термин, впервые введенный в 70-х годах основоположником теории баз данных Дж. Коддом, в современной трактовке отображает совокупность правил порождения структур данных в базах данных, последовательности их изменения. Различают три основные типа модели данных: иерархический, сетевой и реляционный.

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

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

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

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

Процесс построения концептуальной модели разделяется на следующие этапы:

1) сбор и содержательный анализ априорной информации о предметной области и прикладных задач пользователей;

2) концептуальный анализ данных и синтез концептуальной модели.

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

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

Результатом данного этапа являются:

1) список всех создаваемых и используемых элементов данных;

2) перечень прикладных задач, их характеристик и используемых в них данных;

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

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

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

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

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

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

Декомпозиция должна:

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

· приводить к вычислению элементов, свойства которых могут быть описаны с помощью собранных на первом этапе элементов данных;

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

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

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

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

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

рассмотрения объекта с различных точек зрения, выявления аспектов изучаемого с учетом их взаимосвязи;

расчленения объекта на более простые подсистемы (основанием для введения подсистем является то, что связи между подсистемами много слабее, чем между элементами внутри подсистемы, а каждая подсистема много проще, чем вся система в целом);

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

Системный анализ - это применение системного подхода при обработке конкретной информации и принятию решений. Рассмотренные принципы системного подхода являются и принципами системного анализа.

Их дополняют следующие специфические принципы:

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

· необходимо рассматривать лишь те цели, вероятность достижения которых p>p0 за время t<t0, где p0 и t0 пороги осуществимости цели.

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

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

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

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

Требования, предъявляемые к инфологической модели.

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

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

Желательно, чтобы язык спецификации ИЛМ был одинаково применим как при ручном, так и при автоматизированном проектировании информационных систем. Последнее предъявляет дополнительные требования к нему, а именно он должен:

· быть вычисляемым, т.е. восприниматься и обрабатываться ЭВМ;

· использовать «дружелюбные» пользователю интерфейсы, в частности графические;

· быть не зависимым от оборудования и других ресурсов, которые подвержены частным изменениям;

· использовать средства тестирования ИЛМ, а также иметь аппарат для указания того, что спецификация завершена и по ней может быть выполнена генерация структур баз данных.

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

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

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

Компоненты инфологической модели.

Инфологическая модель предметной области включает в себя ряд компонентов (рис.2). Центральной компонентной инфологической модели является описание объектов предметной области и связей между ними.

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

Рис.2. Компоненты инфологической модели.

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

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

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

Общие сведения о даталогическом проектировании.

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

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

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

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

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

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

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

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

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

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

БД системы ”FoxPro” [5] с определенной степенью строгости можно назвать реляционными. Не вдаваясь в детали определения реляционной модели организации данных, скажем лишь, что пользователем реляционная база данных воспринимается как таблица (или совокупность таблиц). Используя аналогии с двумерной таблицей, мы дадим определение таких понятий, как «запись», «поле», «файл данных». Строку в нашей таблице назовем «записью» (record), а столбец «полем» (Field). «Файл данных» объединяет собственно информацию, хранящуюся в таблице, и информацию о ее структуре.

Запись характеризуется своим номером, а поле имеет «имя поля» (fieldname). Именно указание номера записи и имени поля позволяет осуществить доступ к конкретной единице информации - значению поля данной записи, хранящемуся в ячейке нашей таблицы. Сразу отметим, что в ”FoxPro” имя поля может состоять наиболее, чем из десятки латинских букв или цифр, должно начинаться с буквы, из специальных знаков допустим лишь знак подчеркивания «__».

Помимо имени поле имеет еще две важные характеристики: ширину (width) и тип данных (field type). Ширина указывает, сколько позиций будет отводиться в базе данных для значений данного поля (данные большей длины будут усекаться).

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

”FoxPro” поддерживает шесть различных типов данных

1. Символьные (Character) произвольная строка символов, как правило, заключаемая в двойные или одинарные кавычки. Напомним, что пробел тоже является символом и влияет на длину символьной строки.

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

3. Числовые с плавающей точкой (Float) как и тип Numeric, используются в полях, которые принимают участие в вычислениях. Тип Float занимает больше места в памяти и замедляет работу, но позволяет добиться более высокой точности при выполнении арифметических операций.

Для числовых полей типа Numeric и Float кроме ширины определяется число знаков после десятичной точки. В случае, когда содержимое поля является числом, но не участвует в вычислениях (например, почтовый индекс), следует определять тип поля как Character это ускорит и упростит манипулирование данными.

4. Логические (Logical) данные, которые могут принимать только два значения: «Да» (Yes) или «Правда» (True) и «Нет» (No) или «Ложь» (False). Примером такого типа данных может служить членство в профсоюзе: «Да» (член профсоюза) или «Нет» (не член профсоюза).

5. Дата (Date) тип данных, говорящий сам за себя. Выделен потому, что даты подчиняются собственной арифметике (прибавление дней к определенной дате, определение числа дней между двумя датами и т.д.). Ширина полей этого типа данных автоматически устанавливается равной 8. Дата может выводиться в следующих форматах:

американском (american ММ ДД ГГ);

британском (british ДД / ММ / ГГ);

французском (frensh ДД.ММ..ГГ);

итальянском (italian ДД ММ ГГ);

В стандарте Американского национального института стандартов (ANSI ГГ.ММ..ДД).

Символы ДД, ММ и ГГ обозначают соответственно день, месяц и год конкретной даты. Например, 23 сентября 1996 года в американском формате примет вид 09/23/96.

6. Текстовые (Memo) символьные данные, длина которых не определена заранее. Преимущество типа Memo и Character состоит в том, что размер текста, занесенного в такое поле, может быть довольно большим (до 4096 символов) и на него выделяется столько места, сколько занимает текст (или вообще ничего, если поле пусто). В основном файле данных для полей типа Memo выделяется 10 позиций, а сама информация хранится в отдельном файле с расширением *.dbt.

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

Как правило, конкретная информационная система не ограничивается одним файлом данных. Для удобной и качественной работы приходится создавать различные вспомогательные файлы: индексные файлы, файлы форматов, отчетов, наклеек и т.д. Для этого чтобы объединить все файлы в единую систему, введено понятие «Каталога» (Catalog). Каталог содержит все файлы данных и вспомогательные файлы, необходимые в конкретном приложении. Для каждого файла каталог может содержать краткое описание, позволяющее хранить поясняющую информацию. Еще до включения компьютера необходимо определить, в каких файлах данных и с какой структурой будут храниться связанные отношениями данные. Под структурой файла данных мы будем понимать число полей и их характеристики: имя, тип данных, ширина, число знаков после десятичной точки (для полей типа Numeric и Float).

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

2.1 Современные СУБД для ПК

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

обеспечивать получение общих и/или детализированных отчетов по итогам работы;

позволять легко определять тенденции изменения важнейших показателей;

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

выполнять точный и полный анализ данных.

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

Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

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

2.2 Принципы организации данных, лежащие в основе СУБД

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

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

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

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

Объект (Сущность) - элемент какой-либо системы, информация о котором сохраняется. Объект может быть как реальным (например, человек), так и абстрактным (например, событие - поступление человека в стационар).

Атрибут - информационное отображение свойств объекта. Каждый объект характеризуется набором атрибутов.

Таблица - упорядоченная структура, состоящая из конечного набора однотипных записей.

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

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

3.Структура объекта управления

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

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

Основными задачами учета товаров являются:

ь правильный и своевременный учет наличия и движения товаров на складах, холодильниках и других местах хранения продукции;

ь контроль за выполнением планов по объему, ассортименту, качеству приобретенных товаров и обязательств по их поставкам;

ь контроль за сохранностью товаров и соблюдением установленных лимитов;

ь контроль за выполнением плана по реализации продукции и своевременностью оплаты за реализованную продукцию;

ь выявление рентабельности всей продукции и ее отдельных видов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реализация продукции (работ, услуг) производится организациями по следующим ценам:

по свободным отпускным ценам и тарифам, увеличенным на сумму НДС;

по государственным регулируемым оптовым ценам и тарифам, увеличенным на сумму НДС (продукция топливно-энергетического комплекса и услуги производственно-технического назначения);

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

Расчеты по межреспубликанским поставкам товаров (работ, услуг) с государствами, подписавшими договор об экономическом сотрудничестве, осуществляются по ценам и тарифам, увеличенным на сумму НДС.

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

Основанием для отгрузки товаров покупателям или отпуска ее со склада служат обычно приказы отдела сбыта (маркетинга) организации (см. Приложение 10).

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

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

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

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

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

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

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

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

- в оптовую торговлю;

- в розничную торговлю;

- отдельно в магазины, входящие в единую торговую систему одной организации с центральным складом;

- в магазины, являющиеся дочерними обществами;

- в магазины и торговые организации, не зависимые от организации - владельца товаров.

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

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

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

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

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

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

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

Опираясь на общетеоретические сведения инфологического моделирования, приведенные нами в главе I, описание объекта - предмета нашего исследования получаем схему инфологической модели

Сделки (otch_all.dbf)

Отчет (otchet.dbf)

Поставщики (post.dbf) Товары (tovar.dbf)

Фирма поставщик Наименование тов.

Наименование тов. Модель

ФИО директора Характеристики

Город Цена

Адрес Количество

Телефон

Покупатели (pokup.dbf)

Фирма покупатель

ФИО директора

Город

Адрес

Телефон

Тарифы (tariff.dbf)

Место доставки

Стоимость

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

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

TOVAR.DBF
№	Наименование	Расшифровка	Тип	Размер
1	NAIM_T	Наименование товара	C	12
2	MOD	Модель товара	C	8
3	HAR	Характеристика	C	8
4	CENA	Цена	N	6_0
5	KOL	Количество	N	6_0

POSD.DBF
№	Наименование	Расшифровка	Тип	Размер
1	FIRM_PS	Название фирмы поставщика	C	12
2	NAIM_T	Наименование товара	C	12
3	FIO_D	ФИО директора	C	15
4	GOR	Город	C	12
5	ADR	Адрес	C	20
6	TEL	Телефон	C	6

POKUP.DBF
№	Наименование	Расшифровка	Тип	Размер
1	FIRM_PS	Название фирмы покупателя	C	12
2	FIO_D	ФИО директора	C	15
3	GOR	Город	C	12
4	ADR	Адрес	C	20
5	TEL	Телефон	C	6

OTCHET.DBF
№	Наименование	Расшифровка	Тип	Размер
1	FIRM_PS	Название фирмы покупателя	C	12
2	FIRM_PS	Название фирмы поставщика	C	12
3	NAIM_T	Наименование товара	C	12
4	FIO_D	ФИО директора	C	15
5	GOR	Город	C	12
6	ADR	Адрес	C	20
7	TEL	Телефон	C	6
8	MOD	Модель товара	C	8
9	HAR	Характеристика	C	8
10	CENA	Цена	N	6_0
11	KOL	Количество	N	6_ 0
12	SUM_SD	Сумма сделки	N	6_0
13	DOST	Место доставки	C	12
14	ITOGO	Итого	N	8_0
15	DAT	Дата сделки	C	16

OTCH_ALL.DBF
№	Наименование	Расшифровка	Тип	Размер
1	FIRM_PS	Название фирмы покупателя	C	12
2	FIRM_PS	Название фирмы поставщика	C	12
3	NAIM_T	Наименование товара	C	12
4	MOD	Модель товара	C	8
5	HAR	Характеристика	C	8
6	CENA	Цена	N	6_0
7	KOL	Количество	N	6_0
8	SUM_SD	Сумма сделки	N	6_0
9	DOST	Место доставки	C	12
10	ITOGO	Итого	N	8_0
11	DAT	Дата сделки	C	16

5.Связь баз данных

База Товары проиндексирована по полю наименование товара (naim_t),

его индексом является Nm_t.

База Поставщики проиндексирована по полю название фирмы поставщика (firm_ps),его индексом является f_k.

База Покупатели проиндексирована по полю наименование товара (firm_pk), его индексом является f_s.

База Тарифы проиндексирована по место доставки (dost), его индексом является d_t.

База Отчет является главной и связана со всеми вышеперечисленными базами.

Модель данных.

Процедура:

Wwod - активизирует вертикальное меню wwod.

Wwod1 - активизирует вертикальное меню ww1.

Vivod - активизирует вертикальное меню vi.

Prosm - активизирует вертикальное меню d1.

Prosm1 - открывает для просмотра базу Товары.

Prosm2 - открывает для просмотра базу Поставщики.

Prosm3 - открывает для просмотра базу Покупатели.

Prosm4 - открывает для просмотра базу Тарифы.

Prosm5 - открывает для просмотра базу Сделки.

Poisk - активизирует вертикальное меню p1.

Poisk1 - активизирует вертикальное меню pk1.

Poisk2 - активизирует вертикальное меню pk2.

Poisk3 - активизирует вертикальное меню pk3.

Pravka - активизирует вертикальное меню pr.

Reduk - активизирует вертикальное меню rr1.

Udalit - активизирует вертикальное меню uu1.

Udal1 - удаляет все записи из базы Товары.

Udal2 - удаляет все записи из базы Поставщики.

Udal3 - удаляет все записи из базы Покупатели.

Udal4 - удаляет все записи из базы Тарифы.

Udal5 - удаляет все записи из базы Сделки.

Spravka - активизирует вертикальное меню dat.

Spravka1 - выводит информацию о программе.

Vi1 - выводит на печать содержимое базы Отчет.

Vi2 - выводит в файл 111.txt содержимое базы Отчет.

Vi3 - выводит на экран содержимое базы Отчет.

Otchet - осуществляет ввод данных и математические операции необходимые для покупки товара

Hlp - запускает справку FoxPro.

Wihod - активизирует вертикальное меню vih.

Wihod1 - осуществляет выход в FoxPro.

Wihod2 - осуществляет выход в Dos.

A1 - производит поиск данных по наименованию товара.

A2 - производит поиск данных по модели товара.

A3 - производит поиск данных по количеству товара

A4 - производит поиск данных по цене товара

B1 - производит поиск данных по наименованию поставляемого товара.

B2 - производит поиск данных по названию фирмы поставщика.

B3 - производит поиск данных по ФИО директора фирмы поставщика.

B4 - производит поиск данных по № телефона фирмы поставщика.

C2 - производит поиск данных по названию фирмы покупателя.

C3 - производит поиск данных по ФИО директора фирмы покупателя.

C4 - производит поиск данных по № телефона фирмы покупателя.

Qqqq - активизирует окно просмотра результатов поиска.

Vv_t - осуществляет ввод данных в базу Товары.

Vv_pk - осуществляет ввод данных в базу Покупатели.

Vv_ps - осуществляет ввод данных в базу Поставщики.

Vv_tar - осуществляет ввод данных в базу Тарифы.

Заключение

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

Эта программа позволяет произвести:

Ввод:

по сделке, товару, по поставщику, по покупателю;

Просмотр:

по сделке, товару, по поставщику, по покупателю;

Фильтрацию:

по товару, по поставщику, и по покупателю;

Поиск:

по товару, по поставщику, и по покупателю;

Вывод:

по списку сделок в порядке возрастания;

Выход:

в FoxPro и в MSDOS.

Литература

1. Кокорева Л.И., Малацин И.И. Проектирование банков данных. М., 1984. 256 с.

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

3. Замулин А.В. Системы программирования баз данных и знаний. Новосибирск, 1990. 352 с.

4. Корнеев В.В., Гареев А.Ф., Васютин С.В., Райх В.В. База Данных. Интеллектуальная обработка информации. М., 2000. 352 с., ил.

5. Мусина Т.В., Пушенко В.А. Visual Fox Pro 7.0. Учебный курс. Киев, 2002. 400 с.

6. Вербонец А.А. Основы проектирования баз данных. М.,2000.88 с., ил.

7. Кузнецов С.Д. СУБД и файловые системы М., 2001. 176 с.

8. Диго С.М. Проектирование баз данных. М., 1988. 216 с., ил

Приложение

база данное система управление

close all

clos data

set talk off

set message wind mess

use tovar in a

use post in b

use pokup in c

use otchet in d

use tarif in e

use otch_all in f

sele a

index on naim_t to nm_t

sele c

index on firm_pk to f_k

sele e

index on dost to d_t

sele b

index on firm_ps to f_s

sele b

set relation to naim_t into a

sele d

set relation to dost into e

set relation to firm_pk into c

set relation to firm_ps into b

set relation to naim_t into a

***************************************

on key label alt+x do wihod1

***************************************

define wind gm from 0,0 to 21,79 doub fill '_'color b/n+ footer 'alt+x выход'

activ wind gm

define wind mess from 22,0 to 24,79 color scheme 9;

title '****Сообщение****'double

defi menu greatmenu in wind gm shadow color scheme 3

defi pad a1 of greatmenu prompt '\<Данные ' message 'Осуществляется ввод информации'

defi pad a2 of greatmenu prompt '\<Поиск ' message 'Осуществляется поиск информации'

defi pad a3 of greatmenu prompt '\<Правка ' message 'Осуществляется добавление/удаление информации'

defi pad a4 of greatmenu prompt '\<Справка ' message 'Вывод справки'

on selec pad a1 of greatmenu do wwod

on selec pad a2 of greatmenu do poisk

on selec pad a3 of greatmenu do pravka

on selec pad a4 of greatmenu do spravka

****************************************

defi popu wwod from 1,1 to 11,15 shadow color gr+/w

defi bar 1 of wwod prompt '\<ПРОСМОТР 'message'Просмотр баз данных'

defi bar 2 of wwod prompt '\------------------'

defi bar 3 of wwod prompt '\<ВВОД 'message'Ввод данных'

defi bar 4 of wwod prompt '\------------------'

defi bar 5 of wwod prompt '\<ВЫВОД 'message'Вывод данных'

defi bar 6 of wwod prompt '\------------------'

defi bar 7 of wwod prompt '\<БЛАНК ПОКУПКИ'message'Ввод данных для покупки'

defi bar 8 of wwod prompt '\------------------'

defi bar 9 of wwod prompt '\<ВЫХОД'message'Выход'

on sele bar 1 of wwod do prosm

on sele bar 3 of wwod do wwod1

on sele bar 5 of wwod do vivod

on sele bar 7 of wwod do otchet

on sele bar 9 of wwod do wihod

*************************************

defi popu ww1 from 3,16 shadow color gr+/w

defi bar 1 of ww1 prompt '\<Товары '

defi bar 2 of ww1 prompt '\ -------------'

defi bar 3 of ww1 prompt '\<Поставщики'

defi bar 4 of ww1 prompt '\ -------------'

defi bar 5 of ww1 prompt '\<Покупатели'

defi bar 6 of ww1 prompt '\ -------------'

defi bar 7 of ww1 prompt '\<Тарифы'

on sele bar 1 of ww1 do vv_t

on sele bar 3 of ww1 do vv_ps

on sele bar 5 of ww1 do vv_pk

on sele bar 7 of ww1 do vv_tar

**********************************

defi popu vi from 5,16 shadow color gr+/w

defi bar 1 of vi prompt '\<На принтер '

defi bar 2 of vi prompt '\ -------------'

defi bar 3 of vi prompt '\<В файл'

defi bar 4 of vi prompt '\ -------------'

defi bar 5 of vi prompt '\<На экран'

on sele bar 1 of vi do vi1

on sele bar 3 of vi do vi2

on sele bar 5 of vi do vi3

*********************************

defi popu d1 from 1,16 shadow color gr+/w

defi bar 1 of d1 prompt '\<Товары '

defi bar 2 of d1 prompt '\ -------------'

defi bar 3 of d1 prompt '\<Поставщики'

defi bar 4 of d1 prompt '\ -------------'

defi bar 5 of d1 prompt '\<Покупатели'

defi bar 6 of d1 prompt '\ -------------'

defi bar 7 of d1 prompt '\<Тарифы '

defi bar 8 of d1 prompt '\ -------------'

defi bar 9 of d1 prompt '\<Сделки'

on sele bar 1 of d1 do prosm1

on sele bar 3 of d1 do prosm2

on sele bar 5 of d1 do prosm3

on sele bar 7 of d1 do prosm4

on sele bar 9 of d1 do prosm5

*************************************

defi popu pr from 1,20 shadow color gr+/w

defi bar 1 of pr prompt '\<Редактирование'

defi bar 2 of pr prompt '\----------------'

defi bar 3 of pr prompt '\<Удаление'