46910 (607990), страница 2

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

Текст из файла (страница 2)

«Адрес» - адрес контрагента в формате: город, улица, дом (строение), офис;

«Телефон» - контактный телефон контрагента;

«Факс» - номер факса;

«E-mail» - адрес электронной почты;

«ИНН/КПП» - идентификационный налоговый номер / код причины постановки на учет. Данные реквизиты рассматриваем в совокупности, так как используются они в основном вместе.

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

«Расчетный счет» - расчетный счет поставщика в банке.

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

Сущность «Банк».

Банк мы решили выделить в качестве сущности, так как банки часто у различных контрагентов одни и те же, и поэтому отпадает необходимость по несколько раз вводить одно и то же. К тому же существуют классификаторы банков Российской Федерации, в которых указаны все их реквизиты: БИК, корр-счет, адрес, наименование. И их при необходимости можно просто загрузить. Все эти реквизиты выступают в роли атрибутов в сущности банк.

«БИК» - банковский идентификационный код – уникальный идентификатор;

«Наименование» - наименование банка;

«Корр – счет» - корреспондентский счет. Используется в случае непрямых расчетов;

«Адрес» - адрес банка.

Модель сущность – связь приведена на схеме 1.

Схема1 - Концептуальная схема даталогической модели

3. Разработка информационной системы

3.1 Требования к информационной системе

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

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

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

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

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

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

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

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

3.2 Выбор языка программирования

Выдвигаемые требования к средствам разработки в общем виде можно сформулировать как: "быстрота, простота, эффективность, надежность".

В качестве языка программирования самой базы был выбран SQL. SQL (Structured Query Language) - это язык программирования, который используется при работе с реляционными базами данных в современных СУБД (ORACLE, dBASE IY, dBASE Y, Paradox, Access и др.).

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

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

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

Особо стоит обратить внимание на мощную и гибкую работу с базами данных в Delphi. Она основана на низкоуровневом ядре - процессоре баз данных Borland Database Engine, позволяет осуществлять доступ к данным как с использованием традиционного record-ориентированного (навигационного) подхода, так и с использованием set-ориентированного подхода, используемого в SQL-серверах баз данных. Кроме BDE, Delphi позволяет осуществлять доступ к базам данных, используя технологию (и, соответственно, драйверы) Open DataBase Connectivity (ODBC) фирмы Microsoft. Но, как показывает практика, производительность систем с использованием BDE гораздо выше, чем оных при использовании ODBC. ODBC драйвера работают через специальный “ODBC socket”, который позволяет встраивать их.

Все инструментальные средства баз данных Borland - Paradox, dBase, Database Desktop - используют BDE. Все особенности, имеющиеся в Paradox или dBase, “наследуются” BDE, и поэтому этими же особенностями обладает и Delphi.

Библиотека объектов содержит набор визуальных компонент, значительно упрощающих разработку приложений для СУБД с архитектурой клиент-сервер. Объекты инкапсулируют в себя нижний уровень - Borland Database Engine.

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

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

3.3 Физическое описание базы данных

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

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

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

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

3.4 Выбор типа базы данных

База данных организованна в формате баз данных на платформе SQL Server. Важнейшие характеристики данной СУБД - это:

простота администрирования,

возможность подключения к Web,

быстродействие и функциональные возможности механизма сервера СУБД,

наличие средств удаленного доступа,

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

3.5 Описание таблиц базы данных

База данных представлена двенадцатью таблицами (или по терминологии реляционных баз данных - двенадцатью реляционными отношениями): Nomenklatura, Realiz, Klient, Bank, Material, Edin_izm, Sposob, Vid, MOL. Рассмотрим структуру каждой более подробно.

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

Таблица1 - Nomenklatura.

Первичным ключем является поле Kod_nomen, однозначно определяющее любую запись в таблице. Поля Kod_mater, Kod_edin, Kod_sposob, Kod_specif, Kod_partia, Kod_realiz обеспечивают связь данной таблицы с другими. Также по ним построены вторичные индексы. Индексы – объекты базы данных, которые обеспечивают быстрый доступ к отдельным строкам в таблице. Индекс создается с целью повышения производительности операций запросов и сортировки данных таблицы.

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

X

Таблица 2 - Partia

Здесь ключевым элементом является Kod_partii, а связующими элементами Kod_klient, Kod_sklad, по которым также строятся вторичные индексы, что видно из таблицы.

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

Таблица 3 - Realiz

В данной таблице однозначно идентифицирующий элемент - Kod_Realiz. По полю Kod_klient осуществляется связь данной таблицы с каким – либо контрагентом. Здесь есть поле Cena_Prod из таблицы Nomenklatura, по которому осуществляется автоподстановка цены в документ с возможностью редактирования.

В таблице Klient содержится информация о контрагентах. Информация о полях, их типах, назначениях и ограничениях, накладываемых на поля содержится в таблице 4.

Т

аблица 4 - Klient

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

В таблице Bank представлена информация о банках. Описание данной таблицы дано ниже, в таблице 5.

Т

аблица 5 - Bank

В таблице Bank ключевое поле - Kod_Bank.

Т

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

Характеристики

Список файлов курсовой работы