Контрольная работа по "Информационным технологиям управления"

 

В последнее время организация  применения компьютерной техники претерпевает значительные изменения, связанные  с переходом к созданию интегрированных  информационных систем. Интегрированные  информационные системы создаются  с учетом того, что они должны осуществлять согласованное управление данными в пределах предприятия (организации), координировать работу отдельных подразделений, автоматизировать операции по обмену информацией, как в пределах отдельных групп пользователей, так и между несколькими организациями, отстоящими друг от друга на десятки и сотни километров. Основой для построения подобных систем служат локальные вычислительные сети (ЛВС). Характерной чертой ЛВС является предоставление возможности пользователям работать в универсальной информационной среде с функциями коллективного доступа к данным.

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

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

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

 

 

Глава 2. Реляционные базы данных.

В самом общем смысле база данных - это набор записей и файлов, организованных специальным образом. В компьютере, например, можно хранить  фамилии и адреса друзей или клиентов. Один из типов баз данных - это  документы, набранные с помощью  текстовых редакторов и сгруппированные  по темам. Другой тип - файлы электронных  таблиц, объединяемые в группы по характеру  их использования.

 

2.1. Таблицы в реляционных базах данных

В реляционной базе данных информация организована в виде таблиц, разделённых  на строки и столбцы, на пересечении  которых содержатся значения данных. У каждой таблицы имеется уникальное имя, описывающее её содержимое. Более  наглядно структуру таблицы иллюстрирует рисунок 1, на котором изображена таблица OFFICES.

 

Рисунок 1 – таблица OFFICES

 

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

Каждый вертикальный столбец таблицы OFFICES представляет один элемент данных для каждого из офисов. Например, в столбце CITY содержатся названия городов, в которых расположены офисы. В столбце SALES содержатся объёмы продаж, обеспечиваемые офисами.

На пересечении каждой строки с  каждым столбцом таблицы содержится в точности одно значение данных. Например, в строке, представляющей нью-йоркский офис, в столбце CITY содержится значение "New York". В столбце SALES той же строки содержится значение $692.000.000, которое является объёмом продаж нью-йоркского офиса с начала года.

Все значения, содержащиеся в одном  и том же столбце, являются данными  одного типа. Например, в столбце CITY содержатся только слова, в столбце SALES содержатся денежные суммы, а в  столбце MGR содержатся целые числа, представляющие идентификаторы служащих. Множество значений, которые могут  содержаться в столбце, называется доменом этого столбца. Доменом  столбца CITY является множество названий городов. Доменом столбца SALES является любая денежная сумма. Домен столбца REGION состоит всего из двух значений, "Eastern" и "Western", поскольку у компании всего два торговых региона.

У каждого столбца в таблице  есть своё имя, которое обычно служит заголовком столбца. Все столбцы  в одной таблице должны иметь  уникальные имена, однако разрешается  присваивать одинаковые имена столбцам, расположенным в различных таблицах. На практике такие имена столбцов, как NAME, ADDRESS, QTY, PRICE и SALES, часто встречаются  в различных таблицах одной базы данных.

Столбцы таблицы упорядочены слева  направо, и их порядок определяется при создании таблицы. В любой  таблице всегда есть как минимум  один столбец. В стандарте ANSI/ISO не указывается  максимально допустимое число столбцов в таблице, однако почти во всех коммерческих СУБД этот предел существует и обычно составляет примерно 255 столбцов.

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

В таблице может содержаться  любое количество строк. Вполне допустимо  существование таблицы с нулевым  количеством строк. Такая таблица  называется пустой. Пустая таблица  сохраняет структуру, определённую её столбцами, просто в ней не содержится данные. Стандарт ANSI/ISO не накладывает  ограничений на количество строк в таблице, и во многих СУБД размер таблиц ограничен лишь свободным дисковым пространством компьютера. В других СУБД имеется максимальный предел, однако он весьма высок - около двух миллиардов строк, а иногда и больше.

 

2.2. Первичные ключи

Поскольку строки в реляционной  таблице не упорядочены, нельзя выбрать  строку по ее номеру в таблице. В  таблице нет "первой", "последней" или "тринадцатой" строки. Тогда  каким же образом можно указать  в таблице конкретную строку, например строку для офиса, расположенного в  Денвере?

В правильно построенной реляционной  базе данных в каждой таблице есть один или несколько столбцов, значения в которых во всех строках разные. Этот столбец (столбцы) называется первичным  ключом таблицы. Давайте вновь посмотрим  на базу данных, показанную на рисунке 1. На первый взгляд, первичным ключом таблицы OFFICES могут служить и столбец OFFICE, и столбец CITY. Однако в случае, если компания будет расширяться  и откроет в каком-либо городе второй офис, столбец CITY больше не сможет выполнять роль первичного ключа. На практике в качестве первичных ключей таблиц обычно следует выбирать идентификаторы, такие как идентификатор офиса (OFFICE в таблице OFFICES), служащего (EMPL_NUM в таблице SALESREPS) и клиента (CUST_NUM в таблице CUSTOMES). А в случае; с таблицей ORDERS выбора нет — единственным столбцом, содержащим уникальные значения, является номер заказа (ORDER_NUM).

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

Хотя первичные ключи являются важной частью реляционной модели данных, в первых реляционных СУБД (System/R, DB2, Oracle и других) не была обеспечена явным образом их поддержка. Как правило, проектировщики базы данных сами следили за тем, чтобы у всех таблиц были первичные ключи, однако в самих СУБД не было возможности определить для таблицы первичный ключ. И только в СУБД DB2 Version 2, появившейся в апреле 1988 года, компания IBM реализовала поддержку первичных ключей. После этого подобная поддержка была добавлена в стандарт ANSI/ISO.

 

2.3. Отношения предок/потомок

Одним из отличий реляционной модели от первых моделей представления  данных было то, что в ней отсутствовали  явные указатели, используемые для  реализации отношений предок/потомок  в иерархической модели данных. Однако вполне очевидно, что отношения предок/потомок  существуют и в реляционных базах  данных. Например, в нашей базе данных каждый из служащих закреплен за конкретным офисом, поэтому ясно, что между  строками таблицы OFFICES и таблицы SALESREPS существует отношение. Не приводит ли отсутствие явных указателей в реляционной  модели к потере информации?

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

 

Рисунок 2 – Отношения предок-потомок  в реляционной базе данных

 

На рисунке изображено несколько  строк из таблиц OFFICES и SALESREPS. Обратим  внимание на то, что в столбце REP_OFFICE таблицы SALESREPS содержится идентификатор  офиса, в котором работает служащий. Доменом этого столбца (множеством значений, которые могут в нем  храниться) является множество идентификаторов  офисов, содержащихся в столбце OFFICE таблицы OFFICES. То, в каком офисе  работает Мэри Джонс (Магу Jones), можно узнать, определив значение столбца REP_OFFICE в строке таблицы SALESREPS для Мэри Джонс (число II) и затем отыскав в таблице OFFICES строку с таким же значением в столбце OFFICE (это для офиса в Нью-Йорке). Таким же образом, чтобы найти всех служащих нью-йоркского офиса, следует запомнить значение столбца OFFICE для Нью-Йорка (число II), а потом просмотреть таблицу SALESREPS и найти все строки, в столбце REP_OFFICE которых содержится число 11 (это строки для Мэри Джонс и Сэма Кларка (Sam Clark)).

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

 

2.4. Внешние ключи

Столбец одной таблицы, значения в  котором совпадают со значениями столбца, являющегося первичным  ключом другой таблицы, называется внешним  ключом. На рис. 4.9 столбец REP_OFFICE представляет собой внешний ключ для таблицы OFFICES. Значения, содержащиеся в этом столбце, представляют собой идентификаторы офисов. Эти значения соответствуют  значениям в столбце OFFICE, который  является первичным ключом таблицы OFFICES. Совокупно первичный и внешний  ключи создают между таблицами, в которых они содержатся, такое  же отношение предок/потомок, как  и в иерархической базе данных.

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

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

столбец REP является внешним ключом для таблицы SALESREPS и

связывает каждый заказ со служащим, принявшим его;

столбец CUST является внешним ключом для таблицы CUSTOMES и

связывает каждый заказ с клиентом, разместившим его;

столбцы MRF и PRODUCT совокупно представляют собой составной внешний ключ для таблицы PRODUCTS, который связывает  каждый заказ с заказанным товаром.

Рисунок 3 – Множественные отношения  предок/потомок в реляционной  базе данных

 

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

Внешние ключи являются неотъемлемой частью реляционной модели, поскольку  реализуют отношения между таблицами  базы данных. К несчастью, как и  в случае с первичными ключами, поддержка  внешних ключей отсутствовала в  первых реляционных СУБД. Она была введена в системе DB2 Version 2 и теперь имеется во всех коммерческих СУБД.

 

 

Глава 3. Автоматизированное рабочее место (АРМ)

АРМ должно отвечать следующим требованиям:

- своевременное удовлетворение  информационной и вычислительной  потребности специалиста;

- минимальное время ответа на  запросы пользователя;

- адаптация к уровню подготовки  пользователя и его профессиональным  запросам;

- простота освоения приемов  работы на АРМ и легкость  общения, надежность и простота  обслуживания;

- терпимость по отношению к  пользователю;

- возможность быстрого обучения  пользователя;

- возможность работы в составе  вычислительной сети.

Обобщенная схема АРМ приведена  ниже.