4_Лабораторные, контрольные и самостоятельные работы по информатике_2010

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

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

2xI + xЕ <=6

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

xI + 2xЕ <=8

xI <=2

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

z = 3000xЕ + 2000xI max

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

2xI + xЕ <=6 xI + 2xЕ <=8 xI - xЕ <=1 xI <=2

xI , xЕ >= 0

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

нейно зависят от переменных.

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

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

81

Установите курсор в ячейку С4, выполните пункт меню Сервис/Поиск ре-

шения. Установите переключатель Равной максимальному значению. В поле

Изменяя ячейки укажите ячейки А3:В3.

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

Нажмите кнопку Параметры и в диалоговом окне установите флажок Ли-

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

Приведённые в этом пособии лабораторные и самостоятельные работы по-

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

82

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

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

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

Предметная область – область конкретной практической деятельности. В

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

ния своих задач.

Структурирование – это введение соглашений о способах представления данных. Это понятие близко к понятиям модель данных и формализация дан-

ных. В реляционных базах данных используются три структуры данных: таб-

лица, запись, поле. Каждая из этих структур имеет свои свойства, описываемые параметрами. Таблица имеет имя и состоит из записей. Запись имеет номер в таблице и состоит из полей. У каждого поля есть имя, тип (текстовый, число-

вой и т.п.), длина в байтах. Поясним эти структуры на примере построения ин-

формационной модели конкретной предметной области.

Пусть нас интересует проблема учета всех затрат предприятия, например,

строящего фабрику. Затраты должны учитываться по объектам, видам работ, а

также по организациям-подрядчикам. В соответствии с нашими интересами по-

строим таблицы:

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

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

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

Эл почта]

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

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

Каждая из этих таблиц имеет имя, выделенное полужирным курсивом, и

состоит из записей - строк, состав которых (перечень полей) указан в квадрат-

ных скобках. Имена полей – это имена столбцов таблицы. Курсивом выделены имена ключевых полей. Значение ключевого поля (ключа) однозначно опреде-

ляет запись в таблице. По возрастанию значений ключа СУБД сортирует записи в таблицах.

83

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

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

ектировала и строила мост, подъездную дорогу, трансформаторную подстан-

цию и, возможно, другие объекты. При обработке записей таблицы Затраты

может потребоваться факс этой организации – его легко найти в таблице Орга-

низации, которая должна содержать единственную запись с требуемым нам ко-

дом организации в поле Код орг. Связь между этими таблицами называется связью «один ко многим» (1 ): ссылка на одну запись в таблице Орга-

низации содержится во многих записях таблицы Затраты. Если бы мы ввели еще одну таблицу – Банковские реквизиты, в которой для каждой организа-

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

цей и таблицей Организации была бы связью «один к одному» (1 1), т.к. в

этих таблицах есть только по одной записи с одним и тем же значением ключе-

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

тифицироваться номером цеха и номером бригады в данном цехе.

Для ключевого поля СУБД строит индекс – вспомогательную таблицу, со-

держащую для каждого значения ключа адрес записи в основной таблице. По-

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

ровке подвергается только индекс, но не записи таблицы.

Итак, в нашем примере база данных охватывает несколько взаимосвязан-

ных таблиц «объекты-свойства». Такие базы данных называются реляцион-

ными. Это понятие (relation – отношение) было введено известным американ-

ским специалистом в области систем управления базами данных И.Ф.Коддом.

В 1994 г. отмечалась 25 годовщина с того момента, как И.Ф.Кодд (тогда науч-

ный сотрудник корпорации IBM) предложил реляционную модель. Тем не ме-

нее первая коммерческая реляционная СУБД, названная Oracle [10], появилась только в 1979 г. Она была разработана небольшой компанией Silicon Valley.

Сегодня это Oracle Corporation – крупнейший в мире поставщик реляционных СУБД и сопутствующих программных продуктов. Первой СУБД клиент/сервер

стал выпущенный в 1985 г. Oracle 5. В настоящее время широкое распростра-

84

нение получили более поздние реляционные СУБД, созданные корпорациями

Oracle, Sybase, Microsoft и некоторыми другими. Современные ведущие реля-

ционные СУБД сочетают реляционную модель данных с технологией кли-

ент/сервер и с объектно-ориентированным подходом к созданию программных средств.

Важнейшим достоинством концепции баз данных (в отличие, например, от обработки данных в автономных файлах) является введение набора стандарт-

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

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

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

Только после решения вопросов организации данных приступают к разра-

ботке приложений – многофункциональных программ, осуществляющих пре-

образования данных путем их извлечения из одних таблиц, проведения расче-

тов и размещения результатов в других таблицах базы данных. Такой подход,

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

программированы и входят в состав СУБД – ведь системы управления базами данных как раз и предназначены для создания баз данных и последующего ма-

нипулирования этими данными. СУБД, работающую со структурами данных,

можно сравнить с техническими средствами на современном транспорте – они работают с контейнерами, не зависимо от того, что в этих контейнерах перево-

зится в конкретном случае.

85

5.2. Нормализация отношений (таблиц) и обеспечение целостности

данных в реляционной базе данных

Втерминологии реляционных баз данных таблицы называют отношениями

–ведь, включая в записи таблицы определенные поля, мы устанавливаем отно-

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

оптимизирующие группировку полей - свойств объектов. Такие правила были сформулированы применительно к реляционным базам данных. Это правила нормализации отношений.

Нормализация отношений – формальный аппарат ограничений на фор-

мирование отношений (таблиц), который позволяет устранить дублирование,

обеспечивает непротиворечивость хранимых данных, уменьшает трудозатраты на их ввод и корректировку. И.Ф.Коддом выделены три нормальные формы от-

ношений и предложены методы преобразования отношений к третьей, самой совершенной нормальной форме.

Отношение считается нормализованным, или приведенным к первой нор-

мальной форме, если все его атрибуты (свойства объектов, описываемые в по-

лях записей) простые, т.е. далее неделимы. Отношение Организации (см. п. 5.1)

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

буты, как Город, уже отделены от адреса. Так что, если нам потребуется какая-

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

Отношение находится во второй нормальной форме, если оно приведе-

но к первой нормальной форме, и его каждый неключевой атрибут функцио-

нально зависит от ключа. Функциональная зависимость от ключа означает, что в экземпляре информационного объекта (в записи таблицы) конкретному зна-

чению ключа соответствует определенное значение описательного атрибута.

Так, в таблице Затраты нашего примера коду (например, номеру) каждой за-

86

траты соответствует ее название, код объекта, в который вложены средства, ко-

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

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

бовалась бы функционально полная зависимость атрибутов от ключа. Она за-

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

ставного ключа.

Понятие третьей нормальной формы основывается на понятии нетран-

зитивной зависимости [6]. Транзитивная зависимость наблюдается, если один из атрибутов зависит от ключа, а другой – от этого атрибута. Например, если в таблицу Затраты включить не только код организации, но и город, в котором она расположена, то получится, что атрибут Код орг функционально зависит от ключа Код затр , а атрибут Город зависит, в свою очередь, от атрибута Код орг

и, следовательно, транзитивно зависит от ключа.

Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме, и каждый неключевой атрибут нетранзитивно за-

висит от первичного ключа. Если бы мы включили в записи таблицы Затраты

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

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

Во-вторых, в случае изменения адреса, факса или другой характеристики орга-

низации пришлось бы вносить коррективы не в единственную запись таблицы

Организации, а во множество записей таблицы Затраты.

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

нить дублирование данных, облегчить их ввод и корректировку в базе данных.

Другое важное понятие – обеспечение целостности данных в базе данных.

Этот термин подразумевает, что в СУБД должны иметься средства, не позво-

87

ляющие нарушать корректность и полноту хранимой информации. Например,

СУБД обычно содержат средства поддержания ссылочной целостности. Так,

если мы попытаемся в запись таблицы Затраты ввести код объекта 777, а в таблице Объекты еще нет объекта с кодом 777, то СУБД должна воспрепятст-

вовать нашему намерению, если, конечно, мы выбрали соответствующий ре-

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

Предшествующее изложение основных сведений о реляционных базах дан-

ных иллюстрировалось на примере базы данных Затраты предприятия. Пред-

лагаемая далее лабораторная работа посвящена созданию и использованию этой базы данных с помощью СУБД Access.

5.3. Лабораторная работа «Создание и использование базы данных

“Затраты”»

1. Создание базы данных

Сначала создадим пустую базу данных “Затраты”. Для этого откроем при-

ложение Access, выберем пункт меню Файл/Создать, в открывшемся диалого-

вом окне подтвердим желание создать новую БД нажатием кнопки Ok. После этого откроется стандартное диалоговое окно Сохранить как. В нем надо вы-

брать каталог для размещения новой базы данных и дать имя файлу, например,

Затраты.mdb. Этот файл будет содержать описание структуры таблиц, сами таблицы, формы, запросы и отчеты, которые будут созданы в рамках базы дан-

ных “Затраты”. На рис. 5.1 показано окно приложения Access. В этом окне по-

сле создания пустой базы данных “Затраты” появится окно базы данных с за-

88

головком “Затраты: база данных”, только в этом окне еще не будет перечня таблиц и, конечно, в окне приложения Access еще не будут открыты окна таб-

лиц для просмотра и корректировки наших четырех таблиц (см. п. 5.1). На ри-

сунке эти таблицы показаны заранее, чтобы читатель яснее представлял то, что еще предстоит создать.

2. Создание таблиц базы данных, ввод данных во вспомогательные таблицы

Теперь, когда пустая база данных существует, создадим пустые таблицы,

т.е. пока только определим их структуру – опишем каждое поле записи. Начи-

нать надо со вспомогательных таблиц Объекты, Работы и Организации. Для создания таблицы Объекты в окне базы данных выберем тип объектов, с кото-

рыми собираемся работать, а именно – Таблицы. Теперь нажмем кнопку Соз-

дание таблицы в режиме конструктора. В открывшемся диалоговом окне

(рис. 5.2) сначала создадим таблицу Объекты (на рисунке – слева, внизу). В

графе Имя поля введем Код об, а в поле со списком Тип данных выберем

Числовой. После этого в поле со списком Размер поля выберем Целое. Затем,

нажав на панели инструментов кнопку с изображением ключа, сделаем поле

Код об ключевым. Теперь определим второе поле – поле Объект. В графу

Имя поля введем его название, а в поле со списком Тип данных выберем Тек-

стовый. Длина текстового поля по умолчанию равна 50 байтам, и это нас уст-

раивает. После этого окно, в котором мы определяли поля таблицы Объекты,

можно закрыть с помощью кнопки системного меню (в строке заголовка окна,

справа). При закрытии этого окна появится диалоговое окно, в котором надо задать имя таблицы – “Объекты”. Теперь таблица создана, ее можно открыть с помощью кнопки Открыть в окне базы данных и ввести в нее записи (см. рис. 5.1). Сразу после создания можно ввести большую часть записей во вспомога-

тельные таблицы. Основная таблица Затраты будет пополняться очень долго.

89