Проектирование базы данных

Курсовая работа Дисц.: Математические основы баз данных Тема: Проектирование базы данных

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

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

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

База данных будет разработана в СУБД MS Access, как наиболее удобной и популярной. Содержание создаваемой базы данных не повлияет на её структуру и является примерным.

Общая часть

1. Семантическое моделирование данных

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

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

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

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

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

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

1.1 Семантическое моделирование данных

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

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

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

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

· Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не предоставляет каких-либо средств для представления этих зависимостей.

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

1.2 Основные понятия модели Entity-Relationship

Далее мы кратко рассмотрим некоторые черты одной из наиболее популярных семантических моделей данных — модель «Сущность-Связи» (часто ее называют кратко ER-моделью).

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных. Среди множества разновидностей ER-моделей одна из наиболее развитых применяется в системе CASE фирмы ORACLE. Ее мы и рассмотрим. Более точно, мы сосредоточимся на структурной части этой модели.

Основными понятиями ER-модели являются сущность, связь и атрибут.

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

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

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

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

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

1.3 Нормальные формы ER-схем

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

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

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

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

Мы остановились только на самых основных и наиболее очевидных понятиях ER-модели данных. К числу более сложных элементов модели относятся следующие:

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

· Связи «many-to-many». Иногда бывает необходимо связывать сущности таким образом, что с обоих концов связи могут присутствовать несколько экземпляров сущности (например, все члены кооператива сообща владеют имуществом кооператива). Для этого вводится разновидность связи «многие-со-многими» .

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

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

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

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

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

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

Сущность, на основе которой определяются подтипы, называется супертипом. Подтипы должны образовывать полное множество, т. е. любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты приходится определять дополнительный подтип ПРОЧИЕ.

Пример: Супертип ЛЕТАТЕЛЬНЫЙ АППАРАТ Как полагается это читать? От супертипа: ЛЕТАТЕЛЬНЫЙ АППАРАТ, который должен быть АЭРОПЛАНОМ, ВЕРТОЛЕТОМ, ПТИЦЕЛЕТОМ или ДРУГИМ ЛЕТАТЕЛЬНЫМ АППАРАТОМ. От подтипа: ВЕРТОЛЕТ, который относится к типу ЛЕТАТЕЛЬНОГО АППАРАТА. От подтипа, который является одновременно супертипа: АЭРОПЛАН, который относится к типу ЛЕТАТЕЛЬНОГО АППАРАТА и должен быть ПЛАНЕРОМ или МОТОРНЫМ САМОЛЕТОМ.

Иногда удобно иметь два или более разных разбиения сущности на подтипы. Например, сущность ЧЕЛОВЕК может быть разбита на подтипы по профессиональному признаку (ПРОГРАММИСТ, ДОЯРКА и т. д.), а может — по половому признаку (МУЖЧИНА, ЖЕНЩИНА).

1.4 Получение реляционной схемы из ER-схемы

Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность — сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, — не могут.

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

Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т. е. делается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи — столбцам, не допускающим неопределенные значения.

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

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

· все подтипы в одной таблице (а)

· для каждого подтипа — отдельная таблица (б) При применении способа (а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления. В таблицу добавляется по крайней мере один столбец, содержащий код ТИПА; он становится частью первичного ключа.

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

2. Практическое задание

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

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

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

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

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

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

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

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

Таким образом, входящими документами для покупателя являются:

— счет;

— выписка о состоянии р/с (от банка);

— приходная накладная;

— счет-фактура;

А исходящими документами:

— платежное поручение (банку).

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

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

Основными характеристиками рассматриваемой организации — магазина по продаже расходных материалов — будут следующими:

— Наименование организации (НаимОрг): ООО «Техномир»;

— Адрес организации (АдрОрг): 685 000, Россия, Магадан, ул. Пролетарская 12;

— Телефон организации (ТелОрг): 953 813;

— Факс организации (ФаксОрг): 953 814;

— ФИО руководителя (РукОрг): Петров Петр Петрович;

— Гл. бухгалтер (ГБухОрг): Петрова Анастасия Петровна.

— Идентификационный номер налогоплательщика (ИНН): 5 551 231 245;

— Код причины постановки на учёт (КПП): 984 567 123;

— Общероссийский классификатор предприятий и организаций (ОКПО):12 458 795;

— Расчетный счет (Р/С): 40 227 810 311 164 420 096;

— Наименование Банка (НаимБанк): Магаданское ОСБ № 5448;

— Город банка (ГорБанк): Магадан;

— Банковский Идентификационный Код (БИК): 454 841 451;

— Корреспондентский счет (К/С): 30 000 103 111 199 444 992;

2.1.2Ограничения присутствующие в предметной области

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

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

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

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

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

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

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

— итого (*);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— дата;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

семантический заставка таблица entity relationship

2.2 Проектирование базы данных

2.2.1 Инфологическое моделирование

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

Информационная модель разработанной базы данных представлена на рисунке 2.3

Рисунок. 2.3 Информационная модель Схема данных позволяет установить связи между таблицами и обеспечить целостность данных. Из этой схемы видно, что главными таблицами является таблицы «Товары» и «Заказы», которым подчиняются остальных 5 таблиц. Каждая из них имеет код, по которому осуществляется связь с главными таблицами.

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

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

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

Главными информационными объектами в рассматриваемой предметной области являются наша организация и поставщики. Ниже представлено их описание:

1) Сущность НАША ОРГАНИЗАЦИЯ. Характеризуется следующими атрибутами:

- Идентификационный номер налогоплательщика (ИНН);

— Код причины постановки на учёт (КПП);

— Наименование организации (НаимОрг);

— Адрес организации (АдрОрг);

— Телефон (ТелОрг);

— Факс (ФаксОрг);

— ФИО руководителя (РукОрг);

— Гл. бухгалтер (ГБухОрг);

— Общероссийский классификатор предприятий и организаций (ОКПО);

— Расчетный счет (Р/С);

— Банковский Идентификационный Код (БИК);

— Наименование Банка (НаимБанк);

— Город банка (ГорБанк);

— Корреспондентский счет (К/С).

2) Сущность ПОСТАВЩИКИ. Характеризуется следующими атрибутами:

— Идентификационный номер налогоплательщика (ИНН);

— Код причины постановки на учёт (КПП);

— Наименование организации (НаимОрг);

— Адрес организации (АдрОрг);

— Телефон (ТелОрг);

— Факс (ФаксОрг);

— ФИО руководителя (РукОрг);

— Гл. бухгалтер (ГБухОрг);

— Общероссийский классификатор предприятий и организаций (ОКПО);

— Расчетный счет (Р/С);

— Банковский Идентификационный Код (БИК);

— Наименование Банка (НаимБанк);

— Город банка (ГорБанк);

— Корреспондентский счет (К/С).

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

3) Сущность ТОВАРЫ. Характеризуется следующими атрибутами:

— Наименование товара (НаимТов);

— Код единицы измерения (КодЕдИзм);

— Наименование единицы измерения (НаимЕдИзм);

— Цена товара (Цена);

— Страна происхождения товара (СтранТов);

— Номер таможенной декларации (ДеклТов);

— Вид упаковки (ВидУпак);

— Количество в одном месте (КолВМест).

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

4) Сущность СЧЕТА. Характеризуется следующими атрибутами:

— Номер счета (НомСчет);

— Дата составления счета (ДатаСчет).

5) Сущность ПЛАТЕЖНЫЕ ПОРУЧЕНИЯ. Характеризуется следующими атрибутами:

— Номер поручения (НомПоруч);

— Дата составления поручения (ДатаПоруч);

— Вид поручения (ВидПоруч).

6) Сущность СЧЕТ-ФАКТУРЫ. Характеризуется следующими атрибутами:

— Номер счет-фактуры (НомСчетФ);

— Дата составления счет-фактуры (ДатаСчетФ).

7) Сущность ТОВАРНЫЕ НАКЛАДНЫЕ. Характеризуется следующими атрибутами:

— Номер товарной накладной (НомТовНак);

— Дата составления товарной накладной (ДатаТовНак).

Последние сущности, которые объединяют все документы в одно целое это ЗАКУПАЕМЫЙ ТОВАР и ЗАКУПКИ. Сущность ЗАКУПАЕМЫЙ ТОВАР выступает в роли связующего звена для сущностей ЗАКУПКИ и ТОВАРЫ, обеспечивая связь многие ко многим.

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

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

Результатами анализа проведенного в предыдущем разделе стали 9 сущностей: НАША ОРГАНИЗАЦИЯ, ПОСТАВЩИКИ, ТОВАРЫ, СЧЕТА, ПЛАТЕЖНЫЕ ПОРУЧЕНИЯ, СЧЕТ-ФАКТУРЫ, ТОВАРНЫЕ НАКЛАДНЫЕ, ЗАКУПАЕМЫЙ ТОВАР, ЗАКУПКИ. Каждая сущность характеризуется группой атрибутов, часть из которых может дублироваться в других сущностях. Для оптимизации данных необходимо провести процедуру нормализации, которая выполняется поэтапно.

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

Для приведения сущностей к таблицам первой нормальной форме, необходимо исключить дублирование множества характеристик между двумя сущностями, путем присвоения ключевых атрибутов тем сущностям, которые их не имеют. Так, например, для упоминания поставщика в сущности ЗАКУПКИ нет необходимости дублировать характеристики сущности ПОСТАВЩИКИ, достаточно внести в атрибуты сущности ПОСТАВЩИКИ ключевое поле: Код поставщика (КодПостав). А в сущности ЗАКУПКИ заменить атрибут «Характеристики поставщика» на «Код поставщика», и в дальнейшем связать две этих сущности через созданное поле. Аналогичным образом по необходимости добавляются ключевые атрибуты к другим сущностям.

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

В частности выделение в отдельную сущность информацию о банках позволило исключить дублирование в сущности ПОСТАВЩИКИ.

Сущность БАНКИ. Характеризуется следующими атрибутами:

- Банковский Идентификационный Код (БИК);

— Наименование Банка (НаимБанк);

— Город банка (ГорБанк);

— Корреспондентский счет (К/С).

Для третьей нормальной формы (ЗНФ) требуется, чтобы все не ключевые столбцы таблицы зависели от первичного ключа таблицы, но были независимы друг от друга. Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ.

Сущность ТОВАРЫ не соответствует третьей нормальной форме, так как имеет атрибут зависимый от другого атрибута — Наименование единицы измерения от Кода единицы измерения. Для приведения к третьей нормальной форме из сущности товары была выделена еще одна сущность: ЕДИНИЦЫ ИЗМЕРЕНИЯ.

Сущность ЕДИНИЦЫ ИЗМЕРЕНИЯ. Характеризуется следующими атрибутами:

— Код единицы измерения (КодЕдИзм);

— Наименование единицы измерения (НаимЕдИзм);

В итоге, благодаря нормализации были выделены еще 2 сущности: БАНКИ и ЕДИНИЦЫ ИЗМЕРЕНИЯ. В конечном счете, общие число сущностей стало равно 11. В результате нормализации были добавлены ключевые атрибуты, которые обеспечат связь между сущностями. Данные связи продемонстрированы в следующем разделе.

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

Рисунок 2.4 Инфологическая модель в виде диаграммы «Таблица связь»

2.3 Проектирование даталогической модели

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

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

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

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

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

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

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

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

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

Ниже представлены сущности и их атрибуты виде таблиц реляционной базы данных (РБД) с описанием ограничений и примером заполнения.

Таблица 1. Сущность «НАША ОРГАНИЗАЦИЯ» в виде таблицы РБД

Таблица 2. Описание логической структуры таблицы «НАША ОРГАНИЗАЦИЯ»

Таблица 3. Сущность «ПОСТАВЩИКИ» в виде таблицы РБД

Таблица 4. Сущность «ТОВАРЫ» в виде таблицы РБД

2.3.2 Описание запросов к БД

Запрос «Платежное поручение» должен выбирать следующие данные из базы:

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

— дата выписки;

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

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

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

— назначение платежа: номер счета, дата счета, сумма, сумма НДС Эти данные содержатся в следующих сущностях и их атрибутах:

— ПЛАТЕЖНЫЕ ПОРУЧЕНИЯ: НомПоруч, ВидПоруч, ДатаПоруч;

— НАША ОРГАНИЗАЦИЯ: НаимОрг, Р/С, РукОрг, ГБухОрг, наименование банка, город банка, БИК, корр/с;

— ПОСТАВЩИКИ: НаимОрг, Р/С, РукОрг, ГБухОрг;

— БАНКИ: БИК, НаимБанк, ГорБанк, К/С;

— СЧЕТА: НомСчет, ДатаСчет.

Запрос должен содержать два вычисляемых поля:

Сумма = Суммирование (ЗАКУПАЕМЫЙ ТОВАР! КолМНетто * ТОВАРЫ! Цена);

Сумма НДС = Суммирование (ЗАКУПАЕМЫЙ ТОВАР! КолМНетто * ТОВАРЫ! Цена * ЗАКУПАЕМЫЙ ТОВАР! СтавНДС / 100);

Условия для выборки следующие:

— Атрибут «НомПоруч» равен номеру который будет задан пользователем.

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

Запрос «Сведения о поставщиках», содержит следующие атрибуты:

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

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

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

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

Эти данные содержатся в следующих сущностях и их атрибутах:

— ПОСТАВЩИКИ: НаимОрг;

— ЗАКУПКИ: КодЗакуп (подсчет);

— НАША ОРГАНИЗАЦИЯ: НаимОрг, ИНН, КПП, Р/С, АдрОрг, ТелОрг, РукОрг, ГБухОрг, БИК, К/С;

Запрос должен содержать одно вычисляемое поле:

Сумма = Суммирование (ЗАКУПАЕМЫЙ ТОВАР! КолМНетто * ТОВАРЫ! Цена);

Условий для выборки нет Запрос «Закупленные товары»:

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

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

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

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

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

Эти данные содержатся в следующих сущностях и их атрибутах:

— ТОВАРЫ: КодТов, НаимТов, Цена;

— ЕДИНИЦЫ ИЗМЕРЕНИЯ: НаимЕдИзм;

— ЗАКУПАЕМЫЙ ТОВАР: КолМНетто (суммирование);

— НАША ОРГАНИЗАЦИЯ: НаимОрг, ИНН, КПП, Р/С, АдрОрг, ТелОрг, РукОрг, ГБухОрг, БИК, К/С;

Запрос должен содержать одно вычисляемое поле:

Общая стоимость = Суммирование (ЗАКУПАЕМЫЙ ТОВАР! КолМНетто * ТОВАРЫ! Цена);

Условий для выборки нет Служебные запросы.

2.3.3 Описание содержания и вида выходных документов

Количество выходных документов равняется трем: платежное поручение, отчет «Сведения о поставщиках» и отчет «Закупленные товары».

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

2.4 Проектирование физической модели базы данных

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

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

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

— через раздел СУБД «Таблицы», производя действия по изменению, добавлению или удалению непосредственно в таблице;

— через раздел СУБД «Формы», выполняя необходимые действия в таблице через интерфейс формы;

— через раздел СУБД «Запросы», выполняя запросы на обновление, добавление или удаление данных.

Наиболее приемлемым и удобным является способ ведения базы данных через интерфейс формы.

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

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

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

На рисунках ниже представлены разработанные таблицы в режиме конструктора и в рабочем виде.

Рисунок 1. Таблица «Единицы измерения».

Рисунок 2. Таблица «Счета»

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

Рисунок 3. Схема связей между таблицами БД

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

Рисунок 4. Форма «Наша организация»

Рисунок 4. Форма «Закупки» и подчиненная форма «Закупаемый товар»

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

Рисунок 26. Запрос «Платежное поручение»

Рисунок 28. Запрос «Сведения о поставщиках»

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

Рисунок 33. Отчет «Платежное поручение»

Рисунок 34. Отчет «Закупаемые товары»

Рисунок 35. Отчет «Сведения о поставщиках»

2.5 Разработка формы заставки, главной и вторичных кнопочных форм

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

Рисунок 37. Форма «Заставка»

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

Дополнительные формы, которые были разработаны для удобства пользователя, это формы «Выбор товара» и «Закупка номер».

Источником данных для формы «Выбор товара» является одноименный запрос на выборку. Данная форма доступна из формы «Закупки».

Форма «Закупка номер» появляется при нажатии кнопки во вторичной кнопочной форме «Открыть закупку №».

Эта форма позволяет указать номер закупки (КодЗакуп), после нажатия на кнопку открыть, будет открыта форма «Закупки».

2.6 Инструкция пользователя

Для открытия базы данных запустите файл «.mdb».

После открытия приложения MS ACCESS на экране появится форма «Заставка». Нажатие на кнопку «Приступить к работе» откроет главную кнопочную форму.

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

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

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

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

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

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

Заключение

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

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

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

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

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

Дополнительно, для удобства выбора товаров, были созданы 4 запроса и форма выбора товара.

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

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

1. Акофф Р. Л. Планирование будущего корпорации. М.: Сирин, 2002. 256 с.

2. Ансофф И. Новая корпоративная стратегия. СПб.: Питер Ком, 1999. 416 с.

3. Бестенс Д., В. Ван ден Берг, Д. Вуд Нейронные сети и финансовые рынки. Принятие решений в торговых операциях.-М. ТВП, 1997.

4. Браун М. Г. Сбалансированная система показателей: на маршруте внедрения. М.: Альпина Бизнес Букс, 2005. 226 с.

5. Берман. Б., Эванс Дж.Р. Розничная торговля: стратегический подход. М.: Вильямс, 2003. 1184 с.

6. Боровиков В. П. Прогнозирование в системе STATISTICA в среде Windows. Основы теории и интенсивная практика на компьютере: Учеб.пособие.-М.:Финансы и статистика, 2000. 384с.: ил.

7. Буч Г. Объектно-ориентированное программирование с примерами применения. — Киев: Диалектика, М.:И.В.К., 1992.

8. Горбань. А. Н. Методы нейроинформатики. КГТУ, Красноярск, 1998. 205

9. Гончарук В. А. Развитие предприятия. М.: Дело, 2000. 208 с.

10. Городецкий В. И. Прикладная алгебра и дискретная математика. Часть 3. Формальные системы логического типа. — МО СССР, 1987. — 177 с.

11. Гультяев А. Визуальное моделирование в среде MATHLAB: учебный курс. — СПб: Питер. 2000. — 432 с.

12. Дьяконов В. МАTLAB: учебный курс. — СПб: Питер, 2001. — 560 с.

13. Дьяконов В., Круrлов В. Математические пакеты расширения МАТLAB. Специальный справочник. — СПб: Питер, 2001. — 480 с.

14. Дюбуа Д., Прад А. Теория возможностей. Приложение к представлению знаний в информатике. — М.: Радио и связь, 1990. — 288 с.

15. Иванов О. В. Статистика / Учебный курс для социологов и менеджеров. Часть 1. Описательная статистика. Теоретико-вероятностные основания статистического вывода. — М. 2005. 187 с

16. Hebb D. 1961. Organization of behavior. New York: Science Edition.

17. Rumelhart D. E., Hinton G. E., Williams R. J. 1986. Learning internal reprentations by error propagation. In Parallel distributed processing, vol. 1, pp. 318−62. Cambridge, MA: MIT Press.

18. Werbos P. J. 1974. Beyond regression: New tools for prediction and analysis in the behavioral sciences. Masters thesis, Harward University.

19. Wasserman P. D. 1988a. Combined backpropagation/Cauchy machine. Proceedings of the International Newral Network Society. New York: Pergamon Press

20. Rumelhart D. E., Hinton G. E., Williams R. J. 1986. Learning internal reprentations by error propagation. In Parallel distributed processing, vol. 1, pp. 318−62. Cambridge, MA: MIT Press.

21. Wasserman P. D. 1988b. Experiments in translating Chinese characters using backpropagation. Proceedings of the Thirty-Third IEEE Computer Society International Conference. Washington, D. C.: Computer Society Press of the IEEE.

22. Parker D. B. 1987. Second order back propagation: Implementing an optimal 0(n) approximation to Newton’s method as an artificial newral network. Manuscript submitted for publication.