Офисная техника и ее роль в коммерции

Задание 1. Вопрос № 19. Офисная  техника и ее роль в коммерции.

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

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

КЛАССИФИКАЦИЯ ОФИСНОЙ ТЕХНИКИ

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

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

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

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

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

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

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

 

Задание 2. Вопрос №34. Модели  данных.  Иерархическая,  сетевая,  реляционная  модели баз  данных.

В классической теории баз данных, модель данных есть формальная теория представления и обработки данных в системе управления базами данных (СУБД), которая включает, по меньшей мере, три аспекта:

1) аспект структуры: методы описания типов и логических структур данных в базе данных;

2) аспект манипуляции: методы манипулирования данными;

3) аспект целостности: методы  описания и поддержки целостности  базы данных.

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

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

Каждая БД и СУБД строится на основе некоторой явной или неявной модели данных. Все СУБД, построенные на одной и той же модели данных, относят к одному типу. Например, основой реляционных СУБД является реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархических СУБД — иерархическая модель данных и т.д.

В литературе, статьях и в обиходной  речи иногда встречается использование  термина «модель данных» в  смысле «схема базы данных» («модель  базы данных»). Такое использование  является неверным, на что указывают  многие авторитетные специалисты, в  том числе К. Дж. Дейт, М. Р. Когаловский, С. Д. Кузнецов. Модель данных есть теория, или инструмент моделирования, в то время как модель базы данных (схема базы данных) есть результат моделирования. По выражению К. Дейта соотношение между этими понятиями аналогично соотношению между языком программирования и конкретной программой на этом языке.

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

Тем не менее, длительное время термин «модель данных» использовался  без формального определения. Одним  из первых специалистов, который достаточно формально определил это понятие, был Э. Кодд. В статье «Модели данных в управлении базами данных» он определил модель данных как комбинацию трех компонентов:

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

Уровни восприятия данных

При работе с СУБД разные люди и  разные программы, запускаемые этими  людьми, видят СУБД по-разному. Конечный пользователь работает в каком-то приложении и, скорее всего, ничего не знает о  внутренней структуре. Программа, которую  использует этот пользователь и, соответственно, программист, написавший эту программу, видят и используют ту часть базы данных, которую им разрешено видеть.  Администратор, позволяющий тем  или иным пользователям видеть те или иные данные, видит всю схему  базы данных. Группа программистов, разработавшая  ядро исполнителя запросов (SQL-сервер), и предоставившая администратору возможность  создавать схему базу данных, реализовала  отображение базы данных на внешние устройства и в память.

В соответствии с этим  выделяют три уровня представления данных.

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

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

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

Реализацией физического уровня, как  правило, занимаются специализированные фирмы, такие как Informix Software, Software AG, CA, Oracle Corporation и т.д. Реализацией концептуального и пользовательского уровней занимаются либо программисткие отделы предприятий, либо специализированные фирмы.

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

Иерархическая модель данных

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

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

Попробуем представить себе базу данных для описания тематических сборников  по некоторой теме. Прежде всего, выделим  уровни иерархии. Первый уровень - это  издательства. Каждое издательство характеризуется  своим названием, юридическим адресом, номером счета в банке. Каждое издательство выпускает несколько  сборников. То есть издательство является “родителем” для сборника и связано  с сборником соотношением “издает” (разработчик, естественно, вправе выбрать и другой синоним для данной связи, например “публикует”, “печатает” и т.д.). Для каждого сборника появляются такие атрибуты, как размер, периодичность, цена, ответственный редактор, корректор и т.д. В каждом сборнике есть несколько статей (хотя бы, одна). То есть сборник и статья связаны соотношением “включает”. Далее, у каждой статьи есть название, авторы. Авторы представляются отдельным элементом и образуют следующий уровень иерархии. Каждый автор характеризуется фамилией, именем, отчеством, гонораром и т.д. Статьи связаны с автором соотношением “написаны”. Графическое представление этого примера приведено на Рис.2.2. Элементы нарисованы прямоугольниками, их названия даны обычным шрифтом. Связи нарисованы стрелками и их названия даны курсивом. Обращаем внимание читателей, что атрибуты для каждого элемента на этой схеме не показаны - они являются частью элемента данных.

Рис. 2.2. Графическое представление иерархической модели данных (справа пример какой-то

конкретной базы данных).

Что касается способов описания конкретных схем, базирующихся на иерархической  модели, или языков манипулирования  данными, работающими с такой  моделью, то они зависят от конкретной реализации. Например, в достаточно давно разработанной системе IMS фирмы IBM (эта система является классическим примером иерархической СУБД) схема для нашего примера будет описана следующим образом):

DBD  NAME  = ТЕМАТИЧЕСКИЕ_СБОРНИКИ

SEGM NAME  = ИЗДАТЕЛЬСТВО

FIELD NAME = НАЗВАНИЕ

FIELD NAME = АДРЕС

FIELD NAME = СЧЕТ

SEGM NAME  = СБОРНИК, PARENT = ИЗДАТЕЛЬСТВО

FIELD NAME = НАЗВАНИЕ

FIELD NAME = ПЕРИОДИЧНОСТЬ

FIELD NAME = ЦЕНА

FIELD NAME = ОТВЕТСТВЕННЫЙ_РЕДАКТОР

SEGM NAME  = СТАТЬЯ, PARENT = СБОРНИК

FIELD NAME = НАЗВАНИЕ

SEGM NAME  = АВТОР, PARENT = СТАТЬЯ

FIELD NAME = ФИО

FIELD NAME = ГОНОРАР

В данном примере мы не именовали  явно связи, которые существуют между  разными элементами (в терминологии IMS для нашего понятия “элемент”  используется термин “сегмент”). Язык доступа к данным, который поддерживает IMS позволяет обращаться к элементам напрямую, зная название и, возможно, дополнительное условие. Например, можно распечатать названия всех сборников, ответственным редактором которых является некто по фамилии Буквоедов:

Выбрав один из сборников в предыдущем примере, можно спуститься “вниз” по иерархии и, например, просмотреть  все статьи из выбранного сборника. Для этого существует оператор “движения  вниз по иерархии” GET NEXT WITHIN PARENT. Этот оператор позволяет перебрать все элементы-потомки, принадлежащие выбранному элементу. Предположим, мы хотим напечатать не только названия сборников, но и входящие в них статьи:

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

 

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