Исходные продукты для производства красок

Исходный продукт Расход исходных продуктов на тонну краски, т Максимально возможный запас, т
краска Е краска I
А
В

Изучение рынка сбыта показало, что суточный спрос на краску I никогда не превышает спроса на краску Е более, чем на 1 т. Кроме того, установлено, что спрос на краску I никогда не превышает 2 т в сутки. Оптовые цены одной тонны краски равны: 3000 руб. для краски Е и 2000 руб. для краски I. Какое количество краски каждого вида должна производить фабрика, чтобы доход от реализации продукции был максимальным?

Итак, требуется спланировать объем производства красок так, чтобы максимизировать прибыль. Поэтому переменными являются xI–суточный объем производства краски I и xЕ–суточный объем производства краски Е.

Суммарная суточная прибыль от производства xI тонн краски I и xЕ тонн краски Е равна z = 3000xЕ + 2000xI . Задача заключается в определении среди всех допустимых значений xI и xЕ таких, которые максимизируют суммарную прибыль, т.е. целевую функцию z.

Налагаем ограничения на xI и xЕ.

xI , xЕ = 0 – объем производства красок не может быть отрицательным.

– ограничения на расход исходного продукта

2xI + xЕ

xI + 2xЕ

– ограничения на величину спроса краски

xI — xЕ

xI

В итоге математическая модель имеет следующий вид:

z = 3000xЕ + 2000xI ® max

при следующих ограничениях:

2xI + xЕ

xI + 2xЕ

xI — xЕ

xI

xI , xЕ = 0

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

Выполнение работы

На листе Excel создайте таблицу:

A B C
Переменные
xE xI
Функция цели =3000*A3+2000*B3
Ограничения
=A3+2*B3
=2*A3+B3
=B3-A3
=B3

Установите курсор в ячейку С4, выполните пункт меню Сервис/Поиск решения. Установите переключатель Равной максимальному значению. В поле Изменяя ячейки укажите ячейки А3:В3.

Для ввода ограничений щелкните по кнопке Добавить, в полессылка на ячейкуукажитеА7:А10, установите ? и в поле ограничениеукажите диапазон В7:В10. Нажмите кнопку Добавить. Введите ограничение: А3:В3 ³ 0. После ввода ограничений щелкните по кнопке ОК.

Нажмите кнопку Параметры и в диалоговом окне установите флажок Линейная модель. Для получения результата щелкните по кнопке Выполнить. По окончании решения задачи в ячейках листа получите следующие результаты:

A B C
Переменные
xE xI
3.333333 1.333333
Функция цели 12666.67
Ограничения
-2
1.333333

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

Системы управления базами данных. СУБД Access

Основные понятия

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

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

Структурирование – это введение соглашений о способах представления данных. Это понятие близко к понятиям модель данных и формализация данных. В реляционных базах данных используются три структуры данных: таблица, запись, поле. Каждая из этих структур имеет свои свойства, описываемые параметрами. Таблица имеет имя и состоит из записей. Запись имеет номер в таблице и состоит из полей. У каждого поля есть имя, тип (текстовый, числовой и т.п.), длина в байтах. Поясним эти структуры на примере построения информационной модели конкретной предметной области.

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

Объекты [Код об, Объект],

Работы [Код раб, Работа],

Организации [Код орг, Организация, Индекс, Город, Адрес, Телефон, Факс, Эл почта]

и собственно таблицу для учета затрат

Затраты [Код затр, Затрата, Код об, Код раб, Код орг, Дата, Стоимость].

Каждая из этих таблиц имеет имя, выделенное полужирным курсивом, и состоит из записей — строк, состав которых (перечень полей) указан в квадратных скобках. Имена полей – это имена столбцов таблицы. Курсивом выделены имена ключевых полей. Значение ключевого поля (ключа) однозначно определяет запись в таблице. По возрастанию значений ключа СУБД сортирует записи в таблицах.

Ключевые поля служат также для связывания таблиц. Например, таблица Затраты может содержать множество записей, в которых указан код одной и той же организации-подрядчика. Предположим, одна и та же организация проектировала и строила мост, подъездную дорогу, трансформаторную подстанцию и, возможно, другие объекты. При обработке записей таблицы Затраты может потребоваться факс этой организации – его легко найти в таблице Организации, которая должна содержать единственную запись с требуемым нам кодом организации в поле Код орг. Связь между этими таблицами называется связью «один ко многим» (1 ® ¥): ссылка на одну запись в таблице Организации содержится во многих записях таблицы Затраты. Если бы мы ввели еще одну таблицу – Банковские реквизиты, в которой для каждой организации-подрядчика указали бы ее код, название банка, номера счетов и другие данные, используемые при оформлении платежей, то связь между этой таблицей и таблицей Организации была бы связью «один к одному» (1 ® 1), т.к. в этих таблицах есть только по одной записи с одним и тем же значением ключевого поля Код орг. В некоторых ситуациях ключ может состоять из двух-трех полей и тогда он называется составным. Например, подразделение может идентифицироваться номером цеха и номером бригады в данном цехе.

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

Итак, в нашем примере база данных охватывает несколько взаимосвязанных таблиц «объекты-свойства». Такие базы данных называются реляционными. Это понятие (relation – отношение) было введено известным американским специалистом в области систем управления базами данных И.Ф.Коддом. В 1994 г. отмечалась 25 годовщина с того момента, как И.Ф.Кодд (тогда научный сотрудник корпорации IBM) предложил реляционную модель. Тем не менее первая коммерческая реляционная СУБД, названная Oracle [10], появилась только в 1979 г. Она была разработана небольшой компанией Silicon Valley. Сегодня это Oracle Corporation – крупнейший в мире поставщик реляционных СУБД и сопутствующих программных продуктов. Первой СУБД клиент/сервер стал выпущенный в 1985 г. Oracle 5. В настоящее время широкое распространение получили более поздние реляционные СУБД, созданные корпорациями Oracle, Sybase, Microsoft и некоторыми другими. Современные ведущие реляционные СУБД сочетают реляционную модель данных с технологией клиент/сервер и с объектно-ориентированным подходом к созданию программных средств.

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

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

Бизнес план завода по производству краски, лакокрасочных материалов (ЛКМ)


Похожие статьи.

Понравилась статья? Поделиться с друзьями: