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

Содержание

• Введение
• 1. Общая часть
• 1.1 Неполная функциональная зависимость и теорема Хита
• 2. Практическая часть
• 2.1 Описание предметной области решаемой задачи
• 2.1.1 Описание входных документов
• 2.1.2 Описание выходных документов
• 2.1.3 Описание функциональной схемы программного приложения
• 2.2 Разработка инфологической модели базы данных
• 2.2.1 Описание информационных объектов
• 2.2.2 Нормализация информационных объектов
• 2.2.3 Построение инфологической модели в виде диаграммы "Таблица-связь"
• 2.3 Разработка даталогической модели
• 2.3.1 Описание выбранной СУБД
• 2.3.2 Представление концептуальной схемы в виде таблиц реляционной базы данных и описанием логической структуры таблиц
• 2.3.3 Разработка и реализация пользовательского приложения
• 2.4 Создание физической модели базы данных
• 2.4.1 Описание технологии ведения базы данных
• 2.4.2 Создание структуры БД в СУБД MS ACCESS
• 2.4.2.1 Создание таблиц проектируемой БД
• 2.4.2.2 Схема связей данных
• 2.4.2.3 Создание форм проектируемой БД
• 2.4.2.4 Создание запросов проектируемой БД
• 2.5 Инструкция для пользователя по работе с ИС
• Заключение
• Список использованной литературы


Введение

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

В данной работе исследуется открытое акционерное общество "ММК-МЕТИЗ". Целью исследования является оценка существующих методов учета затрат на предприятии и разработка новых подходов и методов управления затратами.



1. Общая часть

1.1 Неполная функциональная зависимость и теорема Хита

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

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

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

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

Физическое проектирование по определению является зависимым от специфики конкретной целевой СУБД.

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

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

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

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

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

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

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

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

По сути, функциональная зависимость (далее для ее обозначения часто будет использоваться аббревиатура ФЗ) является связью типа "многие к одному" между множествами атрибутов внутри данной переменной отношения. Например, для переменной отношения поставок SP существует функциональная зависимость между множествами атрибутов {S#,P#} и {QTY}. Это означает, что для любого допустимого значения этой переменной отношения справедливы следующие правила.

Для любой заданной пары значении атрибутов S# и Р# существует только одно соответствующее им значение атрибута QTY.

Но одно и то же соответствующее им значение атрибута qty (в общем случае) могут иметь многие разные пары значений атрибутов S# и Р#.

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

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

В англоязычной литературе почти как равноценные употребляются два термина: functional dependence и functional dependency. Согласно нормам использования английского языка, термин dependence следовало бы применять для обозначения самой функциональной зависимости, а термин dependency -- для обозначения зависимых объектов. Однако термин функциональная зависимость часто приходится применять во множественном числе, а в таких случаях термин dependencies кажется более удобным для произношения, чем dependences. Именно это и определяет смешанное использование в литературе обоих терминов.

Для демонстрации основных идей данного раздела используется несколько измененная версия переменной отношения с данными о поставках, которая в дополнение к обычным атрибутам $#, Р# и QTY будет содержать также атрибут CITY, представляющий город соответствующего поставщика. Во избежание путаницы, далее эту измененную переменную отношения мы будем называть SCP. Она представлена на рис. 6.1 в виде таблицы.

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

Рис. 1.1. Пример значения переменной отношения SCP

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

Функциональная зависимость, вариант а. Пусть r является отношением, а X и Y -- произвольными подмножествами множества атрибутов отношения r. Тогда Y функционально зависимо от X, что в символическом виде записывается как X > Y (читается либо как "X функционально определяет Y", либо как "X стрелка Y") тогда и только тогда, когда каждое значение множества х отношения r связано точно с одним значением множества Y отношения r. Иначе говоря, если два кортежа отношения r совпадают по значению х. они совпадают и по значению Y. Например, отношение SCP (см. рис. 1.1) удовлетворяет требованиям приведенной ниже функциональной зависимости, поскольку все кортежи отношения SCP с одинаковыми значениями атрибута S3 имеют одно и то же значение атрибута CITY. { S# } -> {CITY }. На самом деле, это отношение удовлетворяет требованиям сразу нескольких функциональных зависимостей.

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



S# > CITY

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

S# > CITY

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



Здесь SCPX и SCPY -- переменные области значений, принимающие свои значения в области определения переменной отношения SCP.

Выражение s# --> CITY может расцениваться как сокращенный способ представления этой более длинной формулировки.

Упражнение. Приведите алгебраическую версию этого определения.

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

Функциональная зависимость, вариант б. Пусть R является переменной отношения, а х и Y -- произвольными подмножествами множества атрибутов переменной отношения R. Тогда Y функционально зависимо от х. что в символическом виде| записывается как X -> Y (и читается либо как "х функционально определяет Y". либо как "X стрелка Y") тогда и только тогда, когда для любого допустимого значения переменной отношения R каждое значение множества X отношения R связано точно с одним значением множества Y отношения R. Иначе говоря, для любого допустимого значения переменной отношения R, если два кортежа переменной отношения R совпадают по значению X. они также совпадают и по значению Y.

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



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

S# > QTY

QTY > S#

Иначе говоря, такое утверждение, как (например) "количество детапей в каждой поставке данного поставщика одинаково", действительно оказалось истинным для конкретных значений, присутствующих в отношении на рис. 1.1. но ложным для всех возможных допустимых значений переменной отношения SCP.

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

Р# > { Р#, PNAME, COLOR, WEIGHT, CITY }

Действительно, если переменная отношения R удовлетворяет функциональной зависимости А > B и А не является потенциальным ключом, то R обязательно будет характеризоваться некоторой избыточностью. Например, если обратиться к переменной отношения SCP. то наличие в ней функциональной зависимости S# > CITY приведет к тому, что сведения о месте расположения поставщика в определенном городе повторятся много раз (это хорошо видно на рис. 6.1). Подробнее данный вопрос обсуждается в следующей главе.

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

Пусть R{A, B, C} является переменной отношения, где А, B и C -- множества атрибутов этой переменной отношения. Если R удовлетворяет функциональной зависимости А> B, то R равна соединению ее проекций по атрибутам {А, В} и {А, С}.

Если принять, что А-- это атрибут S#, B -- это атрибут status, а C -- это атрибут CITY, то данная теорема подтверждает, как отмечалось выше, что переменная отношения S может быть разбита с помощью операции декомпозиции на проекции по атрибутам {S#, status } и {S#, CITY} без потери информации. В то же время уже известно, что переменная отношения S не может быть разбита без потери информации на проекции по атрибутам {S#, STATUS} и {STATUS, CITY}. Теорема Хита не дает объяснения, почему так происходит. Однако интуитивно ясно, что при такой декомпозиции утрачивается одна из функциональных зависимостей, т.е. функциональная зависимость S# >{S#, STATUS}все еше представлена (благодаря проекции по атрибутам {S#, STATUS}), а функциональная зависимость S# > CITY утрачена.

В заключение можно отметить, что декомпозиция переменной отношения R на проекции Rl, R2,....Rn выполняется без потерь, если R равна соединению R1, R2, ..., Rn.

Примечание. Вероятно, с точки зрения практики следовало бы выдвинуть дополнительное требование, чтобы в соединении обязательно были нужны все проекции R1. R2,.... Rn. Это позволяет гарантировать, что удастся избежать определенной избыточности, которая могла бы возникнуть в ином случае. Например, вряд ли стоит рассматривать декомпозицию переменной отношения S на проекции (скажем) по атрибутам {S#}, {S#, STATUS} и {S#, CITY} как качественную декомпозицию без потерь, хотя S в конечном итоге становится равной соединению этих трех проекций. Для простоты в дальнейшем будем считать, что это дополнительное требование всегда остается в силе (если явно не указано иное).



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

2.1 Описание предметной области решаемой задачи

В данной работе в качестве предметной области рассматривается склад по реализации продукции ОАО "ММК-Метиз". База данных решает следующие задачи: учёт товара, выдача данных о поставщиках и поставляемых ими товарах (фирма - поставщик, его реквизиты, наименование товаров, характеристики, цены), вычисляет суммы оплаты.

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

Исходные данные о складе: склад располагается в нескольких помещениях (6 складов, кассы). У предприятия есть поставщики, осуществляющие поставку товаров на склад.

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

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

2.1.1 Описание входных документов

Входными документами являются:

1. Счет. Он содержит следующие данные:

- номер счета;

- дату составления счета;

- реквизиты поставщика-получателя: наименование, адрес, телефон, ИНН, КПП, номер р/с, название банка, город банка, номер корр/с, БИК, руководитель предприятия поставщика, главный бухгалтер предприятия поставщика;

- реквизиты покупателя-плательщика: наименование;

- перечень товара: наименование товара, единица измерения (ед. изм.), количество, цена, сумма (*);

- итого (*);

- итого НДС (*);

- всего к оплате (*);

- всего наименований (*).

Бланк документа "Счет" представлен в приложении 1.

2. Приходная (товарная) накладная:

- номер документа;

- дата составления;

- реквизиты поставщика: наименование, ИНН, адрес, телефон, р/с, банк, БИК, корр/с, ОКПО, руководитель предприятия поставщика, главный бухгалтер предприятия поставщика;

- реквизиты плательщика: наименование, ИНН, адрес, телефон, р/с, банк, БИК, корр/с, ОКПО;

- перечень товара: товар (наименование, код), ед. изм. (наименование, код по ОКЕИ), вид упаковки, количество (в одном месте, мест, штук), масса брутто, количество (масса нетто), цена, сумма без НДС (*), НДС (ставка, сумма (*)), сумма с учетом НДС (*).

- Итого: масса нетто(*), сумма без учета НДС(*), сумма НДС (*), сумма с учетом НДС (*);

- всего наименований (*);

- масса груза брутто (*);

- всего мест (*).

Бланк документа "Приходная накладная" представлен в приложении 2.

3. Счет-фактура:

- номер счет фактуры;

- дата составления;

- реквизиты продавца: наименование, адрес, ИНН, КПП, руководитель предприятия поставщика, главный бухгалтер предприятия поставщика;

- реквизиты покупателя: наименование, адрес, ИНН, КПП;

- номер платежного поручения покупателя;

- дата платежного поручения покупателя;

- перечень товара: наименование товара, ед. изм. наименование, количество, цена, сумма без НДС (*), НДС ставка, сумма НДС (*), сумма с учетом НДС (*), страна происхождения, номер таможенной декларации;

- всего к оплате: сумма НДС (*), сумма с учетом НДС (*).

Бланк документа "Счет-фактура" представлен в приложении 3.

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

2.1.2 Описание выходных документов

Выходным документом является платежное поручение. Оно содержит следующую информацию:

- номер платежного поручения;

- дата;

- вид платежа;

- реквизиты нашей организации: наименование, ИНН, р/с, наименование банка, город банка, БИК, корр/с, руководитель, главный бухгалтер;

- реквизиты поставщиков: наименование, ИНН, р/с, наименование банка, город банка, БИК, корр/с, руководитель, главный бухгалтер;

- назначение платежа: номер счета, дата счета, сумма, сумма НДС.

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

Бланк документа "Платежное поручение" представлен в приложении 4.

Дополнительные отчеты, которые будут реализованы в базе данных:

1. Отчет "Сведения о поставщиках", содержит следующие атрибуты:

- реквизиты поставщика: наименование;

- количество закупок у поставщика;

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

- реквизиты нашей организации: наименование, ИНН, КПП, Адрес, Телефон, Руководитель, Главный бухгалтер, БИК, р/с.

2. Отчет "Закупленные товары":

- наименование товара, единицы измерения;

- цена на товар;

- количество закупленного товара;

- общая стоимость закупленного товара;

- реквизиты нашей организации: наименование, ИНН, КПП, Адрес, Телефон, Руководитель, Главный бухгалтер, БИК, р/с.

2.1.3 Описание функциональной схемы программного приложения

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

- добавление новых данных в каждую таблицу;

- редактирование уже введенных данных;

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

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

Рисунок 2. Функциональная схема разрабатываемого программного приложения

Список ограничений.

1. Номера документов уникальны;

2. Один счет оплачивается одним платежным поручением;

3. Грузоотправителем и грузополучателем являются поставщик и покупатель соответственно;

4. Используемая валюта: рубль;

5. Реквизиты покупателя и поставщиков постоянны;

6. Стоимость одного экземпляра материала является постоянной.



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

2.2.1 Описание информационных объектов

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

При проектировании таблиц лучше разработать структуру и только затем начинать работу с СУБД Access. При проектировке таблиц, рекомендуется руководствоваться следующими основными принципами:

- Не должно быть повторений и между таблицами.

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

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

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

- Каждое поле должно быть связано с темой таблицы.

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

- В таблице должна присутствовать вся необходимая информация.

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

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

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

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

2.2.2 Нормализация информационных объектов

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

Рис. 1 Изображение связи "Объект - Свойство" для объекта "Tovar"

Рис. 2 Изображение связи "Объект - Свойство" для объекта "Postavschiki"



Рис. 3 Изображение связи "Объект - Свойство" для объекта "Sotrudniki"

Рис. 4 Изображение связи "Объект - Свойство" для объекта "Oformlenie_na_sklad"



2.2.3 Построение инфологической модели в виде диаграммы "Таблица-связь"

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

Рис. 13 Инфологическая модель базы данных склада ОАО "ММК-Метиз"

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

2.3.1 Описание выбранной СУБД

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

Наиболее удобной и популярной системой управления базой данных (СУБД), которая позволит реализовать все необходимые задачи по разработке базы данных и программного приложения является продукт компании Microsoft - Access.

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

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

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

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

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

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



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

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

- Текстовый. Текст или числа, не требующие проведения расчётов.

- МЕМО. Поле этого типа предназначено для хранения небольших текстовых данных (до 64000 символов). Поле этого типа не может быть ключевым или проиндексированным.

- Числовой. Этот тип данных содержит множество подтипов. От выбора подтипа (размера) зависит точность вычислений.

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

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

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

- Дата/Время. Дата и время хранятся в специальном фиксированном формате.

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

- Гиперсвязь. Содержит адреса Web-страниц.

Следующим шагом выполнения работы было построение реляционной схемы базы данных из ER-модели.

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

Tovar (Nomer, Shtrih_kod, Nazvanie, Ed_izm, Cena);

Postavschiki (Kod_post, Satus, FIO, Adres, Tel);

Sotrudniki (Nomer_sotrudnika, FIO, Vozrast, Adres, Tel);

Oformlenie_na_sklad (Kod_ycheta, Товар, Kod_post, Kolichestvo, Nomer_sklada, Tovar_oformil, Tovara_net);

Personal (Nomer_sotr, Kolvo_sotrudnikov, Kod_podrazdeleniya, Doljnost', Data_prihoda, Razryad, Zarplata);

Istoriya_postupleni (Nomer, Nomer_tovara, Data_postupleniya, Kol_vo, Provedeno);

Realizaciya (Nomer_prodaji, Kod_tovara, Kypleno_kol_vo, Data, Kassir, Chec_probit);

ST (Kod_podrazdeleniya, Nazvanie, Opisnie, Nomer);

Doljnosti (Kod_special, Nazvanie, Oklad, Staj_min, Vozrast_max);

Vozvrat (№_p_p, Nomer_prodaji, Pokupatel', Kol_vo_edinic, Data, Oformil, Operaciya, Obmen_na_tovar, Doplata, Prichina);

Pokupateli (Nomer, FIO, Adres, Tel);

Operacii_po_vozvrat (Nomer, Operaciya).

2.3.3 Разработка и реализация пользовательского приложения

Для хранения данных создано 6 таблиц, структура которых приведена в таблицах 1-12.



Таблица 1 - Структура таблицы "Tovar"

Название	Тип
Nomer	Счетчик
Shtrih_kod	Числовой
Nazvanie	Текстовый
Ed_izm	Текстовый
Cena	Денежный

Таблица 2 - Структура таблицы "Postavschiki"

Название	Тип
Kod_post	Счетчик
Satus	Текстовый
FIO	Текстовый
Adres	Текстовый
Tel	Числовой

Таблица 3 - Структура таблицы "Sotrudniki"

Название	Тип
Nomer_sotrudnika	Счетчик
FIO	Текстовый
Vozrast	Числовой
Adres	Текстовый
Tel	Числовой

Таблица 4 - Структура таблицы "Oformlenie_na_sklad"

Название	Тип
Kod_ycheta	Счетчик
Товар	Числовой
Kod_post	Числовой
Kolichestvo	Числовой
Nomer_sklada	Числовой
Tovar_oformil	Числовой
Tovara_net	Логический



Таблица 5 - Структура таблицы "Personal"

Название	Тип
Nomer_sotr	Счетчик
Kolvo_sotrudnikov	Числовой
Kod_podrazdeleniya	Числовой
Doljnost'	Числовой
Data_prihoda	Дата/время
Razryad	Числовой
Zarplata	Числовой

Таблица 6 - Структура таблицы "Istoriya_postypleni"

Название	Тип
Nomer	Счетчик
Nomer_tovara	Числовой
Data_postupleniya	Дата/время
Kol_vo	Числовой
Provedeno	Логический

2.4 Создание физической модели базы данных

2.4.1 Описание технологии ведения базы данных

Для создания базы данных нужно сначала запустить программу Microsoft Office Access 2003, для этого нужно проделать следующие действия: Пуск > Программы > Microsoft Office > Microsoft Office Access 2003. После этого откроется окно программы. Для создания новой базы данных нужно выполняем:

- команду Файл > Создать

- в открывшемся окне диалога "Создание" выбираем "Новая база данных". На экране появится окно с запросом директории для новой базы данных, вводим имя базы Готовая, затем "ОК". После этого появится окно базы данных.

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

2.4.2 Создание структуры БД в СУБД MS ACCESS

2.4.2.1 Создание таблиц проектируемой БД

Выбираем элемент управления >Создание таблиц в режиме конструктора. Теперь необходимо заполнить Имена полей и выбрать Типы данных. По окончании заполнения через меню Файл > Сохранить как сохраняем полученную таблицу с требуемым именем.



Рис. 5 Таблицы базы данных оптового склада в режиме конструктора

база данный access реляционный

Разработаем схему данных, (создание связей между таблицами). Для этого:

­ нажимаем по кнопку на панели инструментов (или команда Сервис, Схема данных). На экране появится окно <<Схема данных>>;

­ щёлкаем по кнопке на панели инструментов (или команда Связи, Добавить таблицу);

­ в появившемся окне будет выделено название одной таблицы. Щелкаем по кнопке <Добавить>, переводим выделение на имя следующей таблицы и щелкните по кнопке <Добавить>. Аналогично добавляем оставшиеся таблицы;

­ закройте окно, щелкнув по кнопке <3акрыть>;

­ чтобы не выполнять все вышеописанные действия, можно просто перетащить мышкой таблицы из окна "Базы данных Таблицы" в окно "Схема данных";

­ создадим связь между таблицами.

­ устанавливаем флажок ("галочку") в свойствах Обеспечение целостности данных, Каскадное обновление связанных полей и Каскадное удаление связанных записей;

­ щелкаем по кнопке <Создать>. Связь будет создана;

2.4.2.2 Схема связей данных

Рисунок 6 отображает полученную схему базы данных. Закрываем окно схемы данных, ответив ДА на вопрос о сохранении макета. Для связи таблиц использовалась следующая схема (см. рис. 6).

Рис.6 Схема данных базы данных склада ОАО "ММК-Метиз"

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

2.4.2.3 Создание форм проектируемой БД

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

Для создания формы нужно открыть вкладку "Формы" окна базы данных и нажать кнопку "Создать"

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

Далее при помощи кнопок (перенести все записи) или (перенести выбранную запись) нужно выбрать поля, которые будут отражены в форме (см. рис. 7). Нажимаем кнопку "Далее".

Затем нужно выбрать внешний вид формы, стиль, задать имя формы и форма готова .

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

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

Рис. 10 Форма для ввода нового поставщика



Рис. 11 Главная форма базы данных

Рис. 12 Загрузочная форма базы данных

Рис.13 Форма для работы со структурой организации

2.4.2.4 Создание запросов проектируемой БД

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

Создадим запросы на наличие и отсутствие товара. Для создания запроса необходимо открыть вкладку "Запросы" окна базы данных, нажать кнопку создать и в появившемся окне выбрать "Простой запрос". В этом случае будет предложено указать список таблиц и их полей. Выбираем таблицу, добавляем необходимые поля, нажимаем кнопку "Далее". На основании этих данных будет создан запрос. Теперь созданные запросы можно использовать в дальнейшем для отчетов по учету товара.

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

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

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

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

Из режима просмотра пользователь может скопировать отчёт в виде отдельного файла текстового редактора Word или электронной таблицы Excel. Для этого необходимо щёлкнуть на кнопке "Связи с Office", расположенной на панели инструментов "Предварительный просмотр".

Для создания отчета следует нужно открыть вкладку "Отчеты" в окне базы данных и нажать кнопку "Создать" в верхней части окна базы данных.

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

В нашей базе данных создано 4 отчета:

- Выручка от продаж;

- Оформление на склад;

- Продано/в наличии;

- Состав подразделений организации.

2.5 Инструкция для пользователя по работе с ИС

Для открытия базы данных запустите файл "Готовая.mdb". После открытия приложения MS ACCESS на экране появится форма "Заставка". Нажатие на кнопку "Приступить к работе" откроет главную кнопочную форму. Пункты главной кнопочной формы открывают вторичные кнопочные формы, таким образом структурно разделяя виды работ с базой данных.



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

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

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

Фиксировать документооборот организации необходимо при помощи форм, на которые ведет кнопочная форма "Реализация товара".

Для работы с закупками нужно воспользоваться кнопочной формой "Оформление поступления товара". Она позволяет открыть конкретную закупку, все закупки или добавить закупку.



Заключение

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

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

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

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

- автоматизация контроля заказов;

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

- своевременное получение информации о сроках оплаты за осуществленные поставки.



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

1. ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов.

2. ГОСТ 19.402-78 ЕСПД. Описание программы.

3. ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению.

4. ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем.

5. Диго С.М. Базы данных: проектирование и использование: Учебник. - М.: Финансы и статистика, 2009. - 592 с.

6. Шигина Н.А. Разработка БД в среде ACCESS/ Метод.разработка. - Пенза: изд. ПТИ, 2010.

7. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2008 - 304с.

8. Базы данных: Учебник для вузов / Под ред. Проф. А.Д.Хомоненко. Изд. 2-е. - МПб.: КОРОНА принт, 2009. - 672с.

9. Дж.Вейскас. Эффективная работа с Microsoft Access 2000. - С.-Птб. : Питер, 2008. - 1040с. ACCESS 7.0 для Windows 95. - Киев: BHV, 1996. - 480с.

10. Джонс Дж. ACCESS 97. Книга ответов. - С.ПТБ: изд. ПИТЕР, 2008.

11. Кэмпбелл М. ACCESS. Ответы. - М.: БИНОМ, 2009.

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