45080 (Ответы к экзамену по специальности Информатик-технолог), страница 4

Любые данные, используемые в программировании, имеют свои типы данных.

Важно! Реляционная модель требует, чтобы типы используемых данных были простыми.

Для уточнения этого утверждения рассмотрим, какие вообще типы данных обычно рассматриваются в программировании. Как правило, типы данных делятся на три группы:

1. Простые типы данных.

1. Структурированные типы данных.

1. Ссылочные типы данных.

1. Простые типы данных

Простые, или атомарные, типы данных не обладают внутренней структурой. Данные такого типа называют скалярами. К простым типам данных относятся следующие типы:

1. Логический.

1. Строковый.

1. Численный.

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

1. Целый.

1. Вещественный.

1. Дата.

1. Время.

1. Денежный.

1. Перечислимый.

1. Интервальный.

1. И т.д.…

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

Основные функции СУБД

Более точно, к числу функций СУБД принято относить следующие:

Непосредственное управление данными во внешней памяти

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

Управление буферами оперативной памяти

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

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

Управление транзакциями

Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.

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

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

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

Тенденции развития

В этом разделе очень кратко рассматриваются основные направления исследований и разработок в области так называемых постреляционных систем, т.е. систем, относящихся к следующему поколению (хотя термин "next-generation DBMS" зарезервирован для некоторого подкласса современных систем).

Хотя отнесение СУБД к тому или иному классу в настоящее время может быть выполнено только условно (например, иногда объектно-ориентированную СУБД O2 относят к системам следующего поколения), можно отметить три направления в области СУБД следующего поколения. Чтобы не изобретать названий, будем обозначать их именами наиболее характерных СУБД.

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

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

Направление Starburst. Основная характеристика: достижение расширяемости системы и ее приспосабливаемости к нуждам конкретных приложений путем использования стандартного механизма управления правилами. По сути дела, система представляет собой некоторый интерпретатор системы правил и набор модулей-действий, вызываемых в соответствии с этими правилами. Можно изменять наборы правил (существует специальный язык задания правил) или изменять действия, подставляя другие модули с тем же интерфейсом.

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

31. Государственный рубрикатор научно-технической информации (ГРНТИ).

Рубрикатор ГСНТИ – иерархическая таблица, предназначенная для обработки информационного потока в органах ГСНТИ. Разработан в соответствии с положением о лингвистическом обеспечении. Основные положения данного рубрикатора разработаны с учетом ГОСТ 749.84. основная задача:

1. направлена на решение задач, связанных с улучшением информационного обслуживания потребителей, пользователей ГСНТИ;

2. направлена на эффективное использование средств ВТ, особенно в сетевом режиме;

3. призвана обеспечить экономию как материальных, так и затрат, связанных с временем и т.д.

Данный рубрикатор издан в 4 издании и зарегистрирован в качестве основного лингвистического средства.

Структура: состоит из 2 таблиц (1 – иерархическая система перечня отраслей знаний, 2 – пр.собой предметный указатель, основных понятий и терминов).

Особенность. Все отрасли знаний делятся на 4 блока:

1. все общественные науки (от 0 до 16 позиций);

2. естественные и точные науки (с 17 - 43);

3. технические и прикладные науки, отрасли экономики (с 44 - 81);

4. отраслевые и комплексные проблемы.

Глубина индексирования – 2-з уровня, все основные разделы представлены в укрупненном виде, наз-ся только крупные разделы. Параллельно с каждым названием даются индексы УДК. В начале каждого раздела указывается история вопроса, новые термины, которые включены в данные разделы и год. В 4-ое издание внесены новые разделы, касающиеся технико-технических науки. Введены – телеинформационная служба, оптическая связь, социальные отрасли.

35.Организационно-распорядительная документация (назначение, процедура издания и оформление).

Вся ОРД составляется на основе ГОСТа России 6.03-98 – унифицированная система документации. На сегодняшний день в документах обязательными являются только 29 реквизитов.

Вся документация любого предприятия разделена на 3 блока:

1. организационные – устав, положение, инструкция, штатное расписание;

1. распорядительные – постановления, решения, приказы, распоряжения, указания;

1. информационно-справочные документы подразделяются на следующие группы документов:

1. информационные;

1. аналитические материалы.

Типовая структура устава. Устав дает право на конкретный вид деятельности: уставной капитал, порядок деятельности, учет и отчетность распределения прибыли, прочие накопления, прекращение деятельности.

Штатное расписание содержит информацию о:

1. численности кадров;

2. уровень образования сотрудников;

3. трудовой стаж по профессии, должности;

4. а также о зар/плате и фонде зар/платы предприятия.

Положения могут быть как на отдельные предприятия, так и на их отделы.

Приказы подразделяются на следующие виды:

1) по организационным вопросам – издаются в случае организации предприятия, его реорганизации или удаления предприятия.;

2) приказ по основной деятельности;

3) приказ по личному составу.

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

*, приказ по основной деятельности разделен на 2 раздела:

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

2 часть – распорядительная часть – указывается кому, что и когда делать.

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

Процедура издания единоличного приказа первым руководителем:

1) обоснование необходимости издания документа;