База данных по учету металлопродукции на платформе SQL Server (стр. 2 из 8)
«Код по ОКЕИ» - Код по общему классификатору единиц измерения, который здесь является ключом.
«Наименование» – это полное наименование соответствующей единицы измерения (штука, метр, тонна). Данный атрибут носит исключительно справочный характер, так как во всех видах учета используется краткое наименование.
«Краткое наименование» - краткое наименование единиц измерения (шт, кг, т, м). Список как полных, так и кратких наименований берется из классификатора единиц измерения.
Сущность «Материал».
Для специалистов по учету металлопродукции важна не только информация о весе, цене, размере товара, но и том из какого материала он изготовлен. Эта информация важна для них, так как довольно часто потребитель обращает на данную характеристику особое внимание. Металлопрокат обычно выступает не как конечный продукт, а как сырье для дальнейшей переработки, строительства и поэтому на передний план при выборе продукции выходят такие показатели, как прочность, качество, термостойкость, твердость. Данные характеристики в первую очередь зависят от того, из какого материала изготовлена продукция. Поэтому в качестве следующей сущности мы выделили материал, из которого товар изготавливается. Безусловно, вся металлопродукция изготовлена из стали, однако она бывает разной. Мы рассмотрим два вида стали: обыкновенного качества и качественную. Более подробно здесь углубляться не станем, так как мы разрабатываем базу данных для фирмы, занимающейся продажей металлопродукции, а не для завода – изготовителя. И такой уровень детализации в рассматриваемой нами области является вполне достаточным.
«Код» - код материала изготовления - ключ. Атрибутами являются
«Наименование» - наименование вида материала
«ГОСТ» - государственный стандарт, который берется из справочника.
Сущность «Способ изготовления».
Ключом здесь будет
«Код» - код способа изготовления.
«Наименование» - название способа изготовления – атрибут рассматриваемой сущности.
Сущность «Агент».
Партию поставляет некое юридическое лицо – контрагент. Контрагентов будем идентифицировать но коду.
«Код» - код контрагента - ключ.
«Полное наименование», «краткое наименование» - атрибуты. Краткое для «внутреннего использования», то есть в самой программе, для более быстрого поиска и более легкого восприятия.
«Контактное лицо» - контактное лицо поставщика. В атрибуте указывается ФИО представителя поставщика или покупателя, с которым осуществляются контакты. Следующие атрибуты хранят информацию о реквизитах поставщика, это
«Адрес» - адрес контрагента в формате: город, улица, дом (строение), офис;
«Телефон» - контактный телефон контрагента;
«Факс» - номер факса;
«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.