Язык MatLab является высокоуровневым. Структурные характеристики системы
 Скачать 0.98 Mb.
|
Описание процесса проектированияПостроение модели данных для модуля выбора поставщика в рассматриваемом коммерческом предприятии начнем с построения логического уровня модели представляющую собой абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Логическая модель данных является универсальной и ни как не связанна с конкретной реализацией СУБД. На рисунке 3.1 представлена логическая модель, построенная для реализации данного проекта. Определим сущности, которыми будем оперировать. Для того чтобы стало возможным произвести автоматизированный выбор поставщика на основе метода анализа иерархий, как минимум должен существовать объект оценки, то есть предприятие и его подразделения. Далее учитывая особенности метода анализа иерархий изложенные в разделе 2, и особенности предметной области в целом можно выделить два класса данных необходимых для решения поставленной задачи: Характеристики товаров; Характеристики поставщиков. Согласно всему вышеизложенному существует возможность перечислить сущности предметной области: Город; Поставщик; Товар. Дальнейшее проектирования логического уровня данных заключается в определении атрибутов каждой сущности. Для сущности Город атрибутами являются (Название города, количество поставщиков, Расстояние, Возможные способы проезда), первичным ключом будет являться (Название города). Для сущности Поставщик атрибутами являются (ID_Поставщика, Название города, Наименование, Качество поставляемых материалов, Сроки поставки груза, Стоимость материалов, Опыт сотрудничества с поставщиками, Надежность), первичным ключом будет атрибут (ID_Поставщика). Ключом для связи с другими сущностями является атрибут (Название города). Для сущности Товар атрибутами являются (ID_Товара, Название города, ID_Поставщика, Наименование товара, Вес, Цена, Количество), первичным ключом в данной сущности будет являться атрибут (ID_Товара). Для связи с внешними сущностями используется два атрибута (ID_поставщика) и (Название города). Независимой сущностью является Город, остальные являются зависимыми сущностями. Сущность город так же является основной, так как определяет наличие ограниченного набора городов. Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются связи. Переходим к представлению физической модели данных отображенной на рисунке 3.2. Физическая модель в отличие от логической зависит от конкретной СУБД, и является отображением системного каталога. В физической модели содержится информация о всех объектах БД и зависит от конкретной реализации СУБД. Если в логической модели не имеет значение, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах – таблицах, колонках, индексах, процедурах и т.д. Long Integer – числовая переменная целого значения. Text – случайная текстовая переменная. Date/time - числовая переменная десятичного значения.  Рис. 3.1 Логическая модель данных автоматизированный информационный логистика поставщик  Рис. 3.2 Физическая модель данных Вывод: В данном разделе работы был обоснован выбор архитектуры проектируемой системы, а так же построены физические и логические модели данных. Алгоритмы выбора поставщика строить нецелесообразно, так как вся необходимая и достаточная информация содержится в математических моделях (см. раздел 2). Реализация выбранного варианта решенияОбоснование выбора СУБДДля программной реализации информационной системы выбора поставщика необходимо выбрать СУБД. Требования предъявляемые к СУБД должны соответствовать условиям и требованиям заказчика, одним из требований является экономическая составляющая, т.е. относительная дешевизна продукта, другой немаловажной составляющей является привязанность к уже установленному ПО, и наконец уровень компьютерной грамотности обслуживающего персонала, т.е. обслуживание знакомых программных продуктов, минимизировать затраты на переобучение персонала. Рассмотрим некоторые из представленных на рынке СУБД, сведённых в таблицу 4.1. Таблица 4.1 Сравнение СУБД
На основании выбранных критериев проведем расчет технико-экномической эффективности MySQL, SQL Server 2000, ORACLE 10g. Оценим их по каждому i-ому показателю качества по 5-ти бальной шкале. Таблица 4.2 Шкала оценок
Определим каждому критерию весовой коэффициент kj, причем kj= Результаты сравнения сведем результаты сравнения в таблицу 4.3. Посчитаем интегральный технико-экономический показатель: Для SQL Server 2000Qs:  ,Для ORACLE 10gQd:  И для MySQL:  Таблица 4.3 Оценка технико-экономической эффективности
Интегральный технико-экономический показатель между MySQL и SQL Server 2000, равен: Q = Qa/ Qs = 3,7/2,1 = 1,76 Между MySQL и ORACLE 10g,равен: Q = Qa/ Qo = 3,7/1,8 = 2,06 На основании проведенных расчетов можно сделать следующий вывод: интегральный технико-экономический показатель больше 1, что говорит в пользу MySQL и о целесообразности выбора данного СУБД. MySQL:является решением для малых и средних приложений. Входит в LAMP. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, благодаря хорошей системе безопасности этого пакета, стабильной работе, высокому быстродействию и хорошей интеграции с соответствующими средствами программирования. В дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы. [5] Разработчики MySQL всегда считали стабильность предметом особой важности. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
