Смекни!
smekni.com

База данных по учету металлопродукции на платформе 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.