Главная Случайная страница


Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






Инструкции предоставления и отмены привелегий

Задание привилегий

Для задания привилегий предназначены инструкции GRANT и REVOKE. Можно также непосредственно манипулировать таблицами привилегий. Но тогда надо выполнить после внесения изменений инструкцию FLUSH PRIVILEGES, после исполнения которой в буфер системы будет перезагружена таблица привилегий. Пароли для таблицы user создаются с помощью функции password().

Проверить существующие привилегии можно:

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

· с помощью инструкции SHOW GRANTS.

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

Перечень привилегий хранится в базе данных mysql. При инсталляции программы в этой базе создаются пять таблиц с описаниями привилегий:

· columns_priv – привилегии отдельных столбцов;

· tables_priv – привилегии отдельных таблиц;

· db – привилегии всей базы данных;

· host – привилегии всех пользователей того или иного узла;

· user – глобальные привилегии.

REVOKE

Инструкция REVOKE отменяет привилегии, выданные ранее инструкцией GRANT. Ее формат такой же, как и у инструкции GRANT:

REVOKE тип [(столбец), …)] [, тип [(столбец, …)] …]

ON таблица

FROM пользователь [, пользователь …]

Типы привилегий те же, что и для инструкции GRANT. Инструкция REVOKE должна соответствовать определенному контексту и распространяет свое действие глобально, на базу данных, таблицу или столбцы.

Привилегии с более узким или более широким контекстом не затрагиваются.

GRANT Инструкция GRANT предоставляет указанным пользователям требуемые привилегии, создавая учетную запись пользователя в случае необходимости. Общий формат инструкции:

 

GRANT (ALL [PRIVILEGES])|(ALTER, CREATE, DELETE, DROP, FILE,

INDEX, INSERT, PROCESS, RELOAD, SELECT, SHUTDOWN, UPDATE,USAGE (список_столбцов))

ON таблица

TO пользователь[@узел] [IDENTIFIED BY пароль]

[, пользователь [IDENTIFIED BY пароль]...]

[WITH GRANT OPTION]

Транзакции и параллельные вычисления

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

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

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

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

 

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

 

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

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

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

Параллельные запросы

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

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

· Менеджер транзакций. Выполняет координацию работы транзакций.

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

§ Менеджер восстановления. Обеспечивает автоматический возврат базы данных в то состояние, в котором она находилась до начала данной транзакции, если во время выполнения транзакции происходит отказ.

§ Менеджер буферов. Отвечает за передачу данных между основной памятью компьютера и дисковой памятью.

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

Программисты решают проблемы параллельного доступа с помощью блокировок.

Информационные хранилища

Хранилище данных (англ. Data Warehouse) — предметно-ориентированная информационная база данных, специально разработанная и предназначенная для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации. Строится на базе систем управления базами данных и систем поддержки принятия решений. Данные, поступающие в хранилище данных, как правило, доступны только для чтения. Данные из OLTP-системы копируются в хранилище данных таким образом, чтобы построение отчётов и OLAP-анализ не использовал ресурсы транзакционной системы и не нарушал её стабильность. Как правило, данные загружаются в хранилище с определённой периодичностью, поэтому актуальность данных может несколько отставать от OLTP-системы.

OLAP технологии

OLAP (OnLine Analytical Processing - оперативная аналитическая обработка) – это динамический синтез, анализ и консолидация больших объемов многомерных данных.

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

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

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

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

Отличие OLAP как инструментария генерации отчетов состоит в возможности автоматически и интерактивно выполнять следующие операции с данными:

· Рекурсивную группировку данных;

· Вычисление промежуточных итогов по подгруппам;

· Вычисление окончательных итогов.

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

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

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

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

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

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

Вычислительное ядро любой OLAP-системы может размещаться на центральном сервере или на стороне клиента.

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

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

Высокая мощность современных ПК и постоянный рост этой мощности позволяет создавать эффективные системы с OLAP-машиной, расположенной на стороне клиента.

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

Создатели многих OLAP-продуктов позволяют доставить отчет не только до пользователя локальной сети предприятия, но и до удаленного пользователя. Для этого используют два основных подхода:

· Удаленный доступ к базе данных по IP-протоколу или через Web-интерфейс;

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

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

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

Особняком стоит OLAP-отчет на основе использования Excel (содержащий базу данных в виде плоской таблицы и настроенный на эту таблицу собственно OLAP-отчет – «сводную таблицу»). Однако у него есть свои особые ограничения: не более 64000 записей, опасность порчи отчета, небольшая функциональность «сводной таблицы». Тем не менее, Excel завоевал огромную популярность именно как самодостаточный контейнер данных и форм их представления.

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

OLTP-технологии

OLTP – это OnLine Transaction Processing – можно перевести как управляемая диалоговая обработка запросов (другая трактовка аббревиатуры OLTP- оперативная обработка транзакций).

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

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

При параллельной работе транзакции конфликтуют за объекты данных, к которым они обращаются.

На данный момент известны следующие стратегии обнаружения и разрешения конфликтов при параллельной работе транзакций:

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

· Пессимистическая стратегия. Основной тезис состоит в том, что транзакция работает параллельно с другими транзакциями и они ей «мешают». Все конфликты (чтения/записи, ограничения целостности, …) проверяются в процессе работы транзакции. Протокол работы требует наличия механизма блокировок, которые накладываются на объекты данных перед выполнением операций и удерживаются или не удерживаются до стадии фиксации транзакции. Для хранения блокировок требуются дополнительные ресурсы, но наиболее дорогой частью механизма является проверка блокировок – не заблокирован ли уже объект. Протокол хорошо работает, когда множества чтения и записи коротких и длинных транзакций пересекаются.

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

 


 

[2] К языкам первого поколения относятся платформно-зависимые машинные коды, напрямую воспринимаемые центральным процессором. Второе поколение- это ассемблерные языки. Языки третьего поколения считаются высокоуровневыми, и на них работают большинство программистов.

Последнее изменение этой страницы: 2016-06-09

lectmania.ru. Все права принадлежат авторам данных материалов. В случае нарушения авторского права напишите нам сюда...