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

Базы данных / Вопросы на собеседовании / Работа для программистов

Некоторые распространенные вопросы на собеседовании по базам данных:

Что такое первичный ключ?

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

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

Например, рассмотрим таблицу заказов, состоящую из столбцов:

• order_id (уникальный номер заказа — первичный ключ)
• order_date (дата совершения заказа)
• order_customer (покупатель, сделавший покупку)
• order_sum (сумма заказа).

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

Что такое внешний ключ?

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

Например, в таблице заказов, очевидно, должно быть поле order_customer, которое определяет покупателя сделавшего покупку. Мы могли бы в это поле записывать просто ФИО покупателя. Но как быть, если нам нужно выбрать все заказы, сделанные конкретным покупателем? Велика вероятность, что в таблице могут находится люди, у которых полностью совпадает ФИО.

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

Например, в таблице заказов будет строка, где в поле order_customer содержится внешний ключ — 3246. Далее в таблице customers необходимо отыскать строку с первичным ключом, равным 3246, в этой строке и будут содержаться все данные покупателя, включая и ФИО.

Что такое нормализация БД?

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

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

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

Первоначально доктором Эдгаром Коддом были определены только 3 нормальные формы. Дальнейшая разработка реляционной теории привела к появлению еще нескольких форм и на данный момент их насчитывается 6.

На практике соответствие базы данных правилам 3-ей нормальной формы вполне достаточно.

Что такое денормализация БД? Для чего она нужна?

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

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

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

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

Что такое кластерный и некластерный индекс?

Индексы делятся на 2 вида — кластерный и некластерный.

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

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

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

Наиболее часто используемые типы индексов:

• B-деревья
• Хеши
• R-деревья
• Полнотекстовые

В отличие от некластерного индекса, таблица может иметь только один кластерный индекс.

Какие типы соединений (join) таблиц существуют? В чем их разница?

Существуют следующие типы соединений таблиц:

• INNER JOIN
• FULL OUTER JOIN
• LEFT OUTER JOIN
• RIGHT OUTER JOIN
• CROSS JOIN

Опишем каждый тип соединений на примере запросов. Рассмотрим 2 таблицы A и B:

A:

ID	NAME
1	Вася
2	Петя
3	Федя
4	Маша

B:

ID	NAME
1	Иван
2	Вася
3	Лена
4	Федя

Посмотрим на результаты следующих запросов:

SELECT * FROM A INNER JOIN B ON A.NAME = B.NAME

ID	NAME	ID	NAME
1	Вася	2	Вася
3	Федя	4	Федя

SELECT * FROM A FULL OUTER JOIN B ON A.NAME = B.NAME

ID	NAME	ID	NAME
1	Вася	2	Вася
2	Петя	null	null
3	Федя	4	Федя
4	Маша	null	null
null	null	1	Иван
null	null	3	Лена

SELECT * FROM A LEFT OUTER JOIN B ON A.NAME = B.NAME

ID	NAME	ID	NAME
1	Вася	2	Вася
2	Петя	null	null
3	Федя	4	Федя
4	Маша	null	null

SELECT * FROM A RIGHT OUTER JOIN B ON A.NAME = B.NAME

ID	NAME	ID	NAME
3	Федя	4	Федя
null	nul	3	Лена
1	Вася	2	Вася
null	null	1	Ivan

SELECT * FROM A CROSS JOIN B

4	Masha	4	Fedya
3	Fedya	4	Fedya
2	Petya	4	Fedya
1	Vasya	4	Fedya
4	Masha	3	Lena
3	Fedya	3	Lena
2	Petya	3	Lena
1	Vasya	3	Lena
4	Masha	2	Vasya
3	Fedya	2	Vasya
2	Petya	2	Vasya
1	Vasya	2	Vasya
4	Masha	1	Ivan
3	Fedya	1	Ivan
2	Petya	1	Ivan
1	Vasya	1	Ivan

CROSS JOIN является полным декартовым произведением, т.е. возвращает все возможные сочетания записей таблиц A и B. В стандартном SQL CROSS JOIN выполняется без условия ON, однако, например, в MySQL этого ограничения нет и CROSS JOIN является аналогом INNER JOIN.

Что такое SQL курсор?

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

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

Опишите шаги по созданию и использованию курсора?

Продемонстрируем использование курсора на простом примере:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

CURSOR cselectitem IS SELECT id, name FROM items; /* Объявляем курсор, привязывая к нему SQL — запрос. */ BEGIN OPEN cselectitem; /* Далее перед использованием курсор необходимо открыть */ LOOP FETCH cselectitem INTO item_id, item_name; /* В цикле вытаскиваем каждую строку, используя конструкцию FETCH, и значения полей выборки записываем в переменные, которые должны быть заранее объявлены */ EXIT WHEN cselectitem%NOTFOUND; /* Выходим из цикла, когда достигнут конец результирующего набора */ END LOOP; CLOSE cselectitem; /* Закрываем курсор */ END

Что такое транзакция?

По определению, транзакция — это логическая единица работы.

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

Начать транзакцию можно при помощи команды BEGIN TRANSACTION. Завершить можно либо сохранив изменения в базе данных при помощи команды COMMIT, либо удалив все сделанные транзакцией изменения командой ROLLBACK

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

1 2 3 4 5 6

BEGIN TRANSACTION UPDATE user_account SET balance=balance-100 WHERE account_id=1 /* Снимаем деньги со счета, ID которого равен 1 */ UPDATE user_account SET balance=balance+100 WHERE account_id=2 /* И переводим эти деньги на счет, ID которого равен 2 */ COMMIT

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

При работе с транзакциями возможны 2 варианта:

• результаты выполнения всех запросов, входящих в транзакцию, будут применены к базе данных
• все внесенные изменения в базу данных будут отменены (откатаны).

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

Что такое блокировка?

Существует 2 вида взаимодействий с базой данных, которые требуют блокировки 2-х разных типов:

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

Что такое deadlock?

Взаимная блокировка (или deadlock) — это ситуация, при которой возник конфликт между несколькими операциями записи.

Рассмотрим пример:

Операция 1	Операция 2
Необходимо изменить данные A и B
Происходит изменение данных A
	Происходит изменение данных B
	Ожидание снятия блокировки с данных A
Ожидание снятия блокировки с данных B

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

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

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

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

Что такое триггер? (Какие типы триггеров вы знаете?)

Триггеры — это части кода, запускаемые автоматически и основанные на каком-либо действии или событии в таблице базы данных.

Триггеры могут применять в таблице во время выполнения операторов INSERT, UPDATE или DELETE, а затем работать или перед, или после этих действий.

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

В чем разница между WHERE и HAVING?

Конструкцию HAVING можно использовать только при наличии конструкции GROUP BY. Она действует по отношению к результатам конструкции GROUP BY аналогично тому, как конструкция WHERE отсеивает строки, возвращаемые оператором SELECT, в соответствии с указанным условием.

Что такое подзапрос (sub-query)?

Подзапрос — это запрос, вложенный в другой запрос.

Несколько примеров подзапросов:

1 2 3 4

SELECT * FROM tableA WHERE id IN (SELECT id FROM tableB) SELECT * FROM tableA WHERE id > (SELECT AVG(id) FROM tableA) SELECT tA.* FROM (SELECT * FROM tableA WHERE col IS NOT NULL) tA, tableB tB WHERE tA.id=tB.id

job-interview.ru

Руководство по проектированию реляционных баз данных (10-13 часть из 15) [перевод]

Продолжение. Предыдущие части: 1-3, 4-6, 7-9

10. Нормализация баз данных

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

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

• В нормализованной структуре базы данных вы можете производить сложные выборки данных относительно простыми SQL-запросами.
• Целостность данных. Нормализованная база данных позволяет надежно хранить данные.
• Нормализация предотвращает появление избыточности хранимых данных. Данные всегда хранятся только в одном месте, что делает легким процесс вставки, обновления и удаления данных. Есть исключение из этого правила. Ключи, сами по себе, хранятся в нескольких местах потому, что они копируются как внешние ключи в другие таблицы.
• Масштабируемость – это возможность системы справляться с будущим ростом. Для базы данных это значит, что она должна быть способна работать быстро, когда число пользователей и объемы данных возрастают. Масштабируемость – это очень важная характеристика любой модели базы данных и для РСУБД.

Вот некоторые из основных пунктов, которые связаны с нормализацией баз данных:

• Упорядочивание данных в логические группы или наборы.
• Нахождение связей между наборами данных. Вы уже видели примеры связей один-ко-многим и многие-ко-многим.
• Минимизация избыточности данных.

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

11. Первая нормальная форма (1НФ)

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

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

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

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

Атомарность.

Правило: поля не имеют дубликатов в каждой записи и каждое поле содержит только одно значение.

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

Горизонтальное дублирование данных – плохая практика.

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

Множественные значения в одной ячейке.

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

Порядок записей не должен иметь значение.

Правило: порядок записей таблицы не должен иметь значения.

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

В следующей части рассмотрим вторую нормальную форму (2НФ).

12. Вторая нормальная форма.

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

Избыточность данных.

Правило: поля с не первичным ключом не должны быть зависимы от первичного ключа.

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

Дублирование данных среди записей в поле store.

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

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

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

В примере выше таблица car имеет внешний ключ – ссылку на таблицы type и store. Столбец brand исчез потому, что на бренд есть неявная ссылка через таблицу type. Когда есть ссылка на type, есть ссылка и на brand, т.к. type принадлежит brand.

Избыточность данных была существенным образом устранена из нашей модели базы данных. Если вы достаточно придирчивы, то вы, возможно, еще не удовлетворены этим решением. А как насчет поля country_of_origin в таблице brand? Пока дубликатов нет потому, что есть только четыре бренда из разных стран. Внимательный разработчик базы данных должен выделить названия стран в отдельную таблицу country.

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

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

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

13. Третья нормальная форма.

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

Транзитивные зависимости.

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

В этой таблице не все поля зависят исключительно от первичного ключа. Существует отдельная связь между полем postal_code и полями города (city) и провинции (province). В Нидерландах оба значение: город и провинция – определяются почтовым кодом, индексом. Таким образом, нет необходимости хранить город и провинцию в клиентской таблице. Если вы знаете почтовый код, то вы уже знаете город и провинцию.

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

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

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

НДС (value added tax) – это процент, который добавляется к цене продукта (19% в данной таблице). Это означает, что значение total_ex_vat может быть вычислено из значения total_inc_vat и vice versa. Вы должны хранить в таблице одно из этих значений, но не оба сразу. Вы должны возложить задачу вычисления total_inc_vat из total_ex_vat или наоборот на программу, которая использует базу данных.

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

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

habr.com

Руководство по поиску литературы в электронном каталоге

В Электронном каталоге библиотеки ОФ РАНХиГС имеются следующие базы данных:

• Поиск книг — в данной базе содержатся библиографические описания всех книг, имеющихся в фонде библиотеки.
• Поиск диссертаций и авторефератов — в данной базе содержатся библиографические описания диссертаций и авторефератов, защищённых в ОФ РАНХиГС, и авторефератов, присланных из других вузов страны.
• Поиск статей периодических изданий — в данной базе содержатся библиографические описания статей из периодических изданий (журналов), имеющихся в фонде библиотеки.
• Поиск в статьях из сборников — в данной базе содержатся библиографические описания статей из научных сборников, изданных в ОФ РАНХиГС, а также библиографические описания статей профессорско-преподавательского состава академии, аспирантов, студентов, опубликованных в других научных сборниках и имеющихся в фонде библиотеки.

1. Отметьте базу данных (в левой части экрана), в которой Вы будете искать необходимую литературу.

2. Поиск литературы может осуществляться:

• по названию;
• по автору;
• по году издания.

Выберите нужное поле для поиска (в правой части экрана).

В поле «Название» Вы можете ввести полное (точное) название документа с целью поиска конкретного издания.

Также Вы можете ввести часть названия (к примеру, «конституционное право» или слово/лучше, часть слова без окончания (к примеру, «инвестиц») для поиска литературы по теме.

Поиск книги или статьи можно осуществлять по фамилии автора, используя поле «Авторы».

Примечание.

В поиске могут быть задействованы два поля. Вы можете указать название/часть названия и автора.

В поиске могут быть задействованы три поля. Можно указать конкретный год требуемого издания (к примеру, если требуются статьи с 2008 года, то отмечаете значок «>» и в пустом поле набираете «2008»; если требуются статьи только 2014 года, то отмечаете значок «=» и набираете «2014»).

3. Кликните «Поиск» для получения списка литературы по заданным параметрам.

ПРИМЕР № 1

Вам необходимо найти книги Баглая М.В. по конституционному праву с 2008 года.

Алгоритм поиска

1. Отметить необходимую базу данных — «Поиск книг».

2. В поле «Название» написать «конституционное право».

3. В поле «Авторы» написать фамилию «баглай».

4. В поле «Год издания» поставить значок «>» и в пустом поле указать год «2008».

5. Кликнуть на поле «Поиск».

ПРИМЕР № 2

Вам необходимо найти статьи по теме «имидж» 2013 года.

Алгоритм поиска

1. Отметить необходимую базу данных — «Поиск статей периодических изданий».

2. В поле «Название» написать слово «имидж».

3. В поле «Год издания» поставить значок «=» и в пустом поле указать год «2013».

4. Кликнуть на поле «Поиск».

РЕЗУЛЬТАТЫ ПОИСКА

1. При поиске книг. Даётся библиографическое описание документа. Также может стоять отметка «Рекомендовано». Это означает, что данное издание рекомендовано или допущено Министерством образования или УМО (только для учебных изданий). В квадратных скобках даётся количество экземпляров данной книги в библиотеке; индекс ББК и Авторский знак (они необходимы для быстрого поиска книги в фонде библиотеки).

2. При поиске авторефератов и статей из периодических изданий даётся библиографическое описание автореферата или статьи.

3. При поиске статей из научных сборников даётся библиографическое описание, индекс ББК и Авторский знак.

Обращаем Ваше внимание: перед каждым новым поиском необходимо очистить заполненные поля!

Перейти к электронному каталогу

old.orel.ranepa.ru

Как отобразить на странице информацию из базы данных

Что такое база данных

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

Упрощенно базу данных можно рассматривать как упорядоченный набор однотипных данных, наподобие картотеки. В определениях базы данных любая карточка в картотеке именуется записью (record), а набор карточек - таблицей (table). Каждый информационный элемент карточки, к примеру: имя клиента, адресок, телефон - именуется полем (field). Поле имеет заглавие (filed name), к примеру «телефон клиента», и значение (field value), к примеру «999-9999». В базе данных может содержаться несколько таблиц, любая из которых отражает некую суть, к примеру: «клиенты», «товары», «документы» и тому схожее Между записями в таблицах, как и между сущностями в реальном мире, могут быть установлены дела в виде ссылок, к примеру записи в таблице «телефоны» ссылаются на запись в таблице «клиент». Не считая таблиц, в состав базы данных могут заходить представления (view). Представления имеют поля и записи, как и таблицы, но в их не хранятся данные. Данные формируются динамически, когда пользователь обращается к представлению, и являются подборкой из одной либо нескольких таблиц, составленной по определенным правилам. В базах данных Microsoft Access представления именуются запросами (query). Таблицы и представления являются объектами базы данных.

Как использовать базу данных

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

Если база данных невелика и организована так, что все ее объекты (таблицы, представления и прочее) содержатся в едином файле, как, к примеру, у Microsoft Access, Microsoft Excel, dBase либо Paradox, можно импортировать базу данных в WEB сайт и сделать соединение на уровне файла. Для импорта можно пользоваться командой меню Файл - Импорт (File - Import), или просто скопировать файл базы данных через буфер обмена в папку WEB сайта.

При импорте файла базы данных Microsoft Access программа FrontPage автоматом создаст соединение и расположит файл в отдельную папку Fpdb, защищенную от просмотра в браузере.

Для работы с большой базой данных, таковой, как MS SQL Server либо Oracle, соединение может быть сотворено через службу System DSN (System Data Source Name - служба системных имен источников данных) для ODBC-совместимых баз данных либо установлено сетевое соединение (network connection) с выделенным сервером баз данных. При всем этом нужно позаботиться, чтобы на WEB cepвepe были сделаны нужные псевдонимы (DSN), а выделенный сервер баз данных был доступен WEB cepвepy.

В состав программки FrontPage заходит особый Мастер результатов базы данных (Database Results Wizard), позволяющий сделать нужный запрос к базе данных и найти метод представления результатов запроса на страничке WEB сайта. Мастер может использовать уже имеющееся соединение либо сделать новое. Не считая того, есть возможность использовать уже готовое соединение с демонстрационной базой данных Борей (Northwind) формата Microsoft Access, которая устанавливается при установки редактора FrontPage. На примере этой демонстрационной базы данных мы разглядим работу мастера.

Как показать информацию из бызы данных на страничке

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

Изберите в меню команду Вставка - База данных - Результаты (Insert - Database - Results). На дисплее появится первый диалог Мастер результатов базы данных (Database Results Wizard).

Установите переключатель подключение к эталону базы данных (Борей) (Use а sample database connection (Northwind)).

При помощи второго переключателя имеющееся подключение к базе данных (Use an existing database connection) можно избрать ранее сделанное соединение, установка переключателя подключение к наружной базе данных (Connection to an external database) позволяет объединиться с наружной базой данных, а установив переключатель новое подключение к базе данных (Use a new database connection), можно сделать новое соединение.

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

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

Если вы знакомы с языком SQL (Structured Query Language - Структурированный язык запросов), то сможете составить свой запрос к базе данных. Для этого нужно установить переключатель Пользовательский запрос (Custom query) и надавить на кнопку Поменять (Edit). При помощи собственного запроса можно получить информацию сходу из нескольких таблиц либо представлений, связав их спецефическим образом. Мастер поможет для вас проверить синтаксическую правильность запроса.

Оставьте установленным переключатель Источник записей (Record source) и изберите в открывающемся перечне одну из таблиц, к примеру Сотрудники (Employees).

Нажмите кнопку Дальше (Next). Мастер загрузит информацию о полях избранной таблицы, и на дисплее появится 3-ий диалог Мастер результатов базы данных (Database Results Wizard).

В перечне в центре диалога перечислены поля избранной таблицы.

Нажмите кнопку Поменять (Edit List). На дисплее появится диалог Отображаемые поля (Displayed fields).

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

Выделите в перечне Отображаемые поля

(Displayed fields) ненадобные поля и перенесите их в перечень Доступные поля (Available fields) при помощи кнопки Удалить (Remove).

Оставьте в перечне Отображаемые поля (Displayed fields) только несколько полей, к примеру: Имя (FirstName), Фамилия (LastName), ДомашнийТелефон (HomePhone) и ДатаРождения (BirthDate), если вы взяли таблицу Сотрудники (Employees).

Чтобы сразу выделить несколько строк перечня, удерживайте нажатой кнопку Ctrl. При помощи кнопок Ввысь (Move Up) и Вниз (Move Down) можно найти порядок отображения полей.

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

Нажмите кнопку Дополнительно (More Options). На дисплее появится диалог Дополнительно (More Options).

Нажав на кнопку Условие (Criteria), можно в отдельном диалоге указать значения либо спектр значений для определенных полей и таким способом отфильтровать нужные записи. Ограничения на значения полей инсталлируются при помощи операций сопоставления и могут объединяться логическими операциями «И» и «ИЛИ». Не считая того, тут же определяются поля для внесения в поисковую форму. Мастер потом может автоматом сделать на страничке поисковую форму, что даст возможность гостю WEB сайта без помощи других отбирать нужные записи из таблицы базы данных. Если заданы поисковые поля, то в диалоге, вызываемом по кнопке По умолчанию (Defaults), можно задать их исходные значения для поисковой формы. Диалог, вызываемый по кнопке Порядок (Ordering), позволяет задать поля для сортировки отображаемых записей. В диалоге Дополнительно (More Options) можно также ограничить полное количество возвращаемых запросом записей (Limit number of returned records to) и указать сообщение на случай, если не найдены записи, удовлетворяющие обозначенному аспекту (Message to display if no records are returned).

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

Нажмите кнопку Дальше (Next). На дисплее появится 4-ый диалог мастера, в каком определяется формат представления данных.

В открывающемся перечне можно избрать три метода представления данных:

Таблица - одна запись в строке (Table - one record per row). Приобретенная информация представляется в виде таблицы, в какой любая строчка соответствует одной записи из базы данных. По умолчанию заголовками колонок таблицы являются наименования полей. При помощи флагов можно включить отображение границ таблицы (Use table border) и заголовков столбцов (Include header row with column labels), также расширить таблицу до ширины странички (Expand table to width of page).

Перечень - одно поле в элементе (List - one field per item). Каждый элемент перечня содержит заглавие поля и его значение. По умолчанию записи отделяются друг от друга горизонтальной линией. В открывающемся перечне Характеристики перечня (List options) можно избрать один из тех типов, к примеру: маркированный либо нумерованный перечень.

Раскрывающийся перечень - одна запись на элемент (Drop-Down List - one record per item). Перечень, в каком отображается значение одного поля из всех записей. Вы сможете поместить таковой открывающийся перечень на форму, чтобы можно было избрать значение поля формы из имеющихся в базе данных. Не считая того, можно указать, что при выборе, к примеру, имени сотрудника, данный элемент формы будет возвращать не само имя, а адресок либо телефон сотрудника. Отображаемое поле указывается в открывающемся перечне Вывести значения из этого поля (Display values from this field), а возвращаемое в открывающемся перечне Отправлять значения из этого поля (Submit values from this field).

Зависимо от избранного варианта в диалоге возникают дополнительные элементы

управления для опции отображения данных.

Изберите, к примеру, табличный вариант представления данных и нажмите кнопку Дальше (Next). На дисплее появится заключительный диалог Мастер результатов базы данных (Database Results Wizard).

Тут можно указать, будут ли все записи отображаться совместно (Display all records together) либо они будут разбиты по группам (Split records into groups) с данным количеством записей. Если установлен флаг Добавить форму поиска (Add search form), то на страничку будет помещена поисковая форма, позволяющая гостю WEB сайта без помощи других находить и отбирать данные. Этот флаг доступен, только если на 3-ем шаге были выбраны поисковые поля.

Нажмите кнопку Готово (Finish), чтобы окончить работу мастера. На дисплее появится диалог, в каком предлагается переименовать страничку так, чтобы она имела расширение ASP.

Нажмите кнопку ОК. На страничку будет помещена таблица для отображения данных.

Вы сможете отредактировать заглавия колонок, расположенные в верхней строке таблицы. Если вы указали поисковые поля и установили флаг Добавить форму поиска (Add search form) в последнем диалоге мастера, то на страничку будет также помещена поисковая форма.

Для правильной работы области отображения данных нужно сохранить страничку в формате ASP (Active Server Pages - Активные серверные странички), воспользовавшись командой Файл - Сохранить как (File - Save As). К огорчению, работу с базой данных нельзя проверить, пока WEB сайт не будет помещен на WEB cepвep, о чем свидетельствует комментарий, помещенный мастером в область отображения данных. Если вы запустите браузер для просмотра странички, то увидите только заглавия колонок.

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

Для сотворения ссылки с параметром щелкните правой кнопкой мыши в области отображения данных на поле, значение которого будет представлено в виде ссылки, к примеру «Фамилия» («LastName»), и в показавшемся контекстном меню изберите команду Ссылка (Hyperlink). На дисплее появится диалог Добавление гиперссылки (Create Hyperlink).

Укажите страничку WEB сайта, файл либо введите адресок ссылки в поле ввода Адресок (URL). Нажмите кнопку Характеристики (Parameters). На дисплее появится диалог Характеристики гиперссылки (Hyperlink Parameters).

Нажмите кнопку Добавить (Add). На дисплее появится диалог Добавление параметра (Add Parameter).

В открывающемся перечне Имя (Name) изберите поле, значение которого будет передаваться в качестве параметра, к примеру, КодСотрудника (EmployeeID). В открывающемся перечне Значение (Value) будет отображен скрипт, вызывающий функцию для получения значения параметра.

Нажмите кнопку ОК. Параметр будет добавлен в перечень характеристик диалога Характеристики гиперссылки (Hyperlink Parameters).

Нажмите кнопку ОК в диалоге Характеристики гиперссылки (Hyperlink Parameters). Мы вернемся в диалог Добавление гиперссылки (Create Hyperlink).

Нажмите кнопку ОК в диалоге Добавление гиперссылки (Create Hyperlink). Выбранное поле воспримет формат ссылки.

Гостям WEB сайта можно дать возможность без помощи других заносить информацию в базу данных. Для этого нужно сделать форму и установить в настройках формы возможность сохранения результата в базе данных. При сохранении данных можно использовать имеющееся соединение либо сделать новый файл базы данных формата Microsoft Access.

sd-company.su

Распространенные ошибки применения баз данных

Сергей Аверин Руковожу разработкой проектов в Баду. Программирую server-side. Конференционный маньяк. Среди проектов, которые я делал — Хабрахабр, dirty.ru, trendclub.ru. Специализируюсь на больших/сложных веб-проектах.

twitter: twitter.com/ryba_xekfacebook: facebook.com/ryba.xek

 

Сергей Аверин: Здравствуйте! Меня зовут Сергей Аверин. Мой доклад посвящен больше архитектуре, чем базам данных. Другое название презентации: "Семь советов стартапам, или что нам стоит дом построить?"

Я работаю в компании "Badoo". Это крупная социальная сеть, которая в основном разрабатывает сайт знакомств. Она предназначена для людей, которым интересно познакомиться с другими людьми, которых они до этого не знали. Мы входим в Top-200 "Alexa" с 2007-го года. Также входим в "Google" Top-100 Sites и почему-то располагаемся выше "Одноклассников" и "Mail.ru". У нас порядка 149-ти миллионов зарегистрированных пользователей. Каждый день регистрируется 150 тысяч новых пользователей. Когда был "Facebook API" – доходило до миллиона.

Ежедневно пользователи загружают порядка 3-х миллионов фотографий. У нас действуют два больших дата-центра: один - в Европе, другой - в Америке. В каждом - примерно тысяча серверов. С точки зрения разработчика, показатели PHP backend, которые формируют сайт, достигают в пике до 30-ти с лишним тысяч динамических запросов в секунду.

Мы часто используем программное обеспечение, расположенное в открытом доступе. Мы также ведем собственные разработки. Основное – это PHP MySQL, PHP FPM, который был написан одним из сотрудников нашей компании, сервис статистики для PHP Pinba. Кроме того, мы самостоятельно модернизируем mem cache, "Linux" (на основе "Suse") и "JANIX".

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

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

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

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

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

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

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

Во-вторых, нельзя забывать об отказоустойчивости.

Что касается отказоустойчивости, на мой взгляд, молодые стартапы берут базы данных с "Full Acid", создают шикарный журнал, "write-ahead log", читают умные книги и утверждают: "Мы все спроектировали правильно. Все отказоустойчиво. Мы ото всего защищены". Но проблемы могут возникнуть, т.к. нижним уровням может уделиться недостаточно внимания.

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

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

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

Кому-то достаточно рисовать 503-ю страницу, если что-то сломалось. Он считает, что это нормально. Для большинства стартапов это так.

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

Самый большой фактор, от которого страдал лично я – это взаимозависимость сбоев. Когда начинает "тормозить" база данных, а за ней – PHP, то все остальное (сеть, switch) тоже начинает создавать неудобства. Обычно так отключаются электростанции. Одна вышла из строя, а за ней через 15 минут все остальные. Как решить проблему – вообще непонятно. Если "поднимать" по одной, то она в конечном счете вернется в неработоспособное состояние.

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

Как это сделано в "Badoo" на примере данных о пользователях? Сразу предупреждаю, что эти данные составляют, наверное, половину всего объема хранимых данных.

В «Badoo» используются специальные БД-серверы проверенного вендера. Мы знаем их failer Raid. Для каждого сервера имеется два блока питания, есть резервирование питания. В ДЦ — дизель-генераторы. В сервере стоит Raid 1+0. Четыре SAS-диска, которые быстро, аккуратно и надежно восстанавливаются. Пожалуйста, не используйте Raid 5 для баз данных.

Следующий уровень – программное обеспечение "Linux" на основе "Suse Linux", с различными правами доступа для разных групп пользователей. Доступ в "MySQL" имеют, по большому счету, только администраторы. В самом "MySQL" пользователи и пароли для разных сервисов тоже отличаются. Стоит "Firewall". Вместо "MySQL" мы весьма выгодно используем Percon-сервер. Также "MySQL" находится в chroot-окружении, что повышает надежность работы.

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

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

В-третьих, стоит позаботиться о резервах БД. Могут ли два сервера выйти из строя одновременно? Это маловероятно. Конечно, нельзя полностью защититься от выгорания дата-центра дотла. В таком случае часть неперенесенных событий действительно будет потеряна. Но, слава Богу, пока такого не происходило.

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

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

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

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

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

В "Badoo" я насчитал три частых use-case. Первая группа – это события, которые порождены транзакциями. Их обязательно нужно записать в той же транзакции, что и изменения данных. Они строго последовательны. Второй случай - это события, которые должны надежно доставляться. Лучше пускай одно событие придет два раза, может быть, поздно, но оно дойдет. Третий момент — это события, которые можно потерять. Мы умеем делать так, чтобы одно событие не приходило дважды, но все-таки главное, чтобы оно не было потеряно.

Самый часто встречающийся use-case — это ведение статистики и сбор определенных логов. Отдельные записи, вероятно, можно потерять, но это не главное.

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

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

У нас в "Badoo" исторически сложилось именно так.

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

Проблемы заключались в следующем. Одна из них состояла в том, чтобы перемещать данные из "MySQL" между площадками. Вторая состояла в одновременном запуске значительного количества (например, двухсот) скриптов. Все пробуют писать в одну таблицу. Поэтому у нас общий лог, разделенный между 200 соединениями в порядке очереди. Поскольку писать приходилось по кругу, процесс шел очень медленно. Третья проблема была связана с процедурой записи, допустим, гигабайтного файла, которая должна длиться в течение целого часа. Если связь по тем или иным причинам обрывалась, то дальнейшие действия оказывались под вопросом. Стоило ли требуемые события дописывать? Или нужно было удалить файл и потерять час рабочего времени? Мы долго мучились с этой ситуацией и создали собственную систему, которую написали поверх движка "Scribe".

"Scribe"– это простой сокет-сервер, написанный специалистами компании "Facebook". Он является "трубой".

Мы написали свой движок агрегации данных, который даже позволяет нам терять "сырые" данные и брать только обработанную информацию, поступившую за последний час. Если нам нужно, мы пишем в базу только счётчик, регистрирующий необходимое количество событий. Это может происходить с периодичностью, которую мы определим сами. Также возможно сделать "Alter Table" адекватно ситуации, при которой возникают какие-либо новые события или устанавливаются новые параметры событий. В базу данных информация может поступать в один поток. Проблема с двумястами скриптами исключена.

Сетевых соединений становится гораздо меньше. Мы не хотим перегружать сеть. На каждой www-машине, которая генерирует события, стоит "Scribe Demon". Мало того, что запись производится локально. Если машина "отваливается" от сети, то "Scribe" сумеет собирать записи и продолжать писать. Когда связь возобновляется, записи направляются в нужное место. Сокет-сервер у нас никогда не падал. Он отличается простой и гибкостью в использовании. Кроме того, удобство применения подчеркиватся возможностью back-end-хранения данных.

Самое главное – "Scribe" очень быстрый. Все сокет-соединения "Scribe Demon" уже открыты. Запись производится в один сокет, которое по открытому коннекту передается дальше по частям этого "дереву". Задержки остаются на уровне миллисекунд. Подобным образом мы пересылаем событие с back-end на некую скриптовую машину, которая далее размещает поступившие данные в БД. Также с помощью "Scribe" мы перемещаем данные между площадками.

Мой пятый совет касается поиска.

Как правило, в стартапах, на мой взгляд, имеет место два сценария. Либо решить задачу своими силами быстро, просто, но плохо (данный подход применяется в 99% случаев). Либо все-таки использовать какой-либо специализированный движок (возможно, на базе Java или C++). Самый популярные варианты – Lucene/Solr/ElasticSearch и, конечно, "Sphinx".

Появляется граница слова, которая ищет слово "one". Не слово "gun". Здесь можно найти, допустим, слово "gun". Приглашаю вас изучить исследования Билла Карвина. Затем переключаемся на "full text index MySQL" и обратные индексы. Все хорошо работает, но процедура поиска вызывает нарекания. Интеграция стоит небольших затрат, но конечный результат неудовлетворительный.

«Percona» провела сравнение между «MySQL» и «Sphinx». Статьи «Википедии» были индексированы на обычном Commodity-сервере. 2,5 миллиона статей, 15 гигабайт «сырого» текста. Sphinx-индексация длилась всего 20 минут. Что касается «MySQL», то даже спустя шесть часов индексация не была завершена.

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

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

Шестой совет: должна быть сильная "consistency".

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

На самом деле сильная «consistency» в вебе нужна не всегда. Кроме того, ее довольно сложно достигнуть. Когда данные перестают помещаться на одном сервере, пожалуйста, используйте грамотный подход посредством «consistency».

В этом плане надо отдать должное «MySQL» и поблагодарить людей в майках «MongoDB». Они делают полезное дело. Зачастую нам все равно, сразу ли увидит Вася комментарий Пети. Главная задача – иметь связанные данные, выдаваемые конкретно одному пользователю. Как это происходит, пользователей совершенно не интересует.

Существует полезный подход – выборочное "выдергивание" записей в базу. Часто имеет место неправильное решение, при котором большое количество обновленных однородных данных пишутся в базу данных, "затирая" самих себя. Происходит сохранение нового состояния.

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

Денормализуйте, денормализуйте, денормализуйте! Это дает прекрасный прирост производительности. Главное – производить изменения, основываясь на здравом смысле.

Есть мы используем SQL-базу данных, то позвольте я переведу часть статьи про нее из английской Википедии. «SQL – база данных. Это консистентное транзакционное хранилище данных, которое гарантирует, что данные хранятся в схеме, которая использует реляционную алгебру для доступа к нормализованным таблицам».

Далее, например, приходит юный системный архитектор и происходит следующее. Мы соединяем ведомый сервер с ведущим, происходит репликация. «Сonsistency» не потеряна. Потом занимаемся mem cache, учитывая возможные высокий нагрузки. К ведомым серверам подключаем другие ведомые серверы, организуем репликации от репликаций, не забывая о шардинге. Когда начинаются проблемы с "Alter table", создаем один столбец на целую таблицу, в котором хранится "JSON blob". Именно он содержит все данные из таблицы.

Что было в самом начале? Много данных, с которыми неумело обращались.

Что стало?

Осталось только "Data store", хранилище данных. И волшебное слово "access". Действительно, доступ остался.  

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

Также, пожалуйста, не поддавайтесь моде на SQL. На мой взгляд, SQL "распиарен", как Дима Билан. Почему?

Во-первых, существует огромный маркетинговый прессинг, "розовый пар". Во-вторых, на мой взгляд, имеет место психологический фактор популярности. Что я имею в виду?

Возьмем условновного программиста-пятикурсника из стартапа. Как обращаться с базой данных, он знает. С MySQL работал. PostgreSQL он "трогал". Однако он очень плохо разбирается в "acid". Кап-теорема ему совершенно незнакома. О третьей нормальной форме он слышал на третьем курсе, но прогулял лекцию. Транзакции когда-то использовал, но не понял зачем. Поэтому мы в стартапе транзакции не используем. А зачем? Все работает. Что касается NoSQL, то программист пытается делать вид, что знания о базах данных не нужны, как и специалист по базам данных.

Какая база данных станет для подобного сотрудника идеальной?

Идеальная БД хранит объекты классов приложения (вроде "JSON blob" или "PHP serialize") в таком виде, в каком я работаю с ними в программе. Кроме того, идеальная БД работает быстро и заботится обо всем остальном сама. 

Когда в стартапе происходит выбор базы данных, технический менеджмент сторонится этой процедуры, доверяя ее программистам. На самом деле это задача технического менеджмента. Почему? Необходимо оценить все риски, окончательную стоимость и принять обоснованное решение из расчета на будущее. В действительности базу данных выбирает программист-середнячок. Что он выбирает? Что больше всех рекламируют: NoSQL. Однако если мы рассматриваем проблему "SQL без NoSQL", то нужно иметь в виду хотя бы следующие пункты.

• Чаще всего, NoSQL – это запись в один поток. Новые записи ждут своей очереди. Если даже запись достаточно велика, пока она не будет обработана до конца, процесс дальше не пойдет.

• Использованием функционала "memory-mappet files", в файловой системе, в который есть свои проблемы с IO scheduling. Непонятно, как он потом "свопит" и "высвопливает" это дело из памяти. Как вообще он работает с памятью. Просто это не рассчитано на базу данных. У этого функционала нет понимания того, с какими данными он работает, какие данные будут нужны дальше. Поэтому он работает, как хочет, а база данных тоже работает, как хочет.

• Как правило, на один индекс приходится один запрос.

• Если есть шардинг, то его нельзя назвать гибким и быстро разворачиваемым.

• Тюнинг производительности осуществляется только на уровне операционной системы. Зачастую атомарность отсутствует даже на уровне одного запроса.

• Неудовлетворительный мониторинг и статистика. Чаще всего приходится писать много однообразного кода, который имитирует сложные запросы.

Но есть и плюсы.

• NoSQL чаще всего быстрее SQL-баз.

• Ей очень просто развертывать (особенно дешевый шардинг).

• Схемы нет, поэтому "Alter table" – больше не проблема.

Что можно сказать насчёт SQL?

• Оно медленнее.

• Сложнее.

• Имеется много каверзных настроек.

• В редких случаях работа протекает по непредсказуемому сценарию. С SQL нужно уметь обращаться.

• Данная база более популярна и очень хорошо изучена. Ей занимаются двадцать лет. Основы реляционной алгебры были заложены еще в 1970-х годах. Язык у всех совпадает на 80%. Можно быстро переключаться между базами данных. Разработчику придётся не очень сильно переучиваться.

Каковы плюсы использования SQL?

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

• Хранение данных зависит от вида данных.

• Множество рычагов оптимизации и сторонних инструментов. Набор полезных свойств, которых пока нет в NoSQL («constraint», триггеры, хранимые процедуры и прочее).

• Full ACID обычный или ACID условный.

• Множество полезных индексов. С их помощью можно решать неординарные задачи (например, выполнять поиск точки на карте). Геопоиск, Р3, B3, Gin, GiST, hash-индексы. Можно создавать индексы с собственной функцией расстояния и т.д.

Продолжим список преимуществ SQL.

• Возможность использовать джойны.

• Эффективный оптимизатор запросов.

• Возможность параллельного использования нескольких запросов. Данная технология прекрасно масштабируется по ядрам.

• Подзапросы иногда тоже исполняются параллельно.

• Многоуровневое кэширование.

• Статистика. Мониторинг.

• Самое главное: можно писать сложные, но плохие запросы. Зато это позволяет не писать длинный код для приложений.

А выводов нет. Нужно думать своей головой.

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

Вопросы и Ответы

Реплика из зала: Если я в своем проекте полностью откажусь от SQL в пользу NoSQL, означает ли это то, что я буду испытывать проблемы с масштабированием и целостностью данных?

Сергей Аверин: Может быть, получите, может, нет. Это во многом зависит от выбираемого решения, построенной архитектуры.

Реплика из зала: Я, наверное, прослушал, почему джойны – зло. Что нужно использовать вместо них?

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

В "Badoo" джойны запрещены как класс. Это было волевым политическим решением.

Реплика из зала: Получается, тогда нужно делать снимки?

Сергей Аверин: Краткий ответ – медленно работают.

Реплика из зала: А как вы боретесь с проблемой?

Сергей Аверин: Если что-то можно хранить в mem cache, храним в mem cache. Или используем в работе, особенно при взаимодействии с малыми массивами. Малый массив надо выбрать в память приложения и «склеить» самостоятельно по ID. Выбрать большой массив или во время выборки доклеивать ручками уже при выводе. Просто делать джоинт в процессе PHP. Либо можете осуществить денормализацию и сохранить данные, обработанные джойнами.

Реплика из зала: Хотел уточнить. NoSQL – проще и быстрее, но не так качественно. SQL – сложно и медленно, но лучше использовать его. NoSQL – это "бензопила". SQL – "молоток". Если человек бьет себе по пальцам молотком, не знает Кап-теорему, это не значит, что он напишет что-то хорошее на SQL.

Сергей Аверин: Рассмотрим широкий круг проблем стартапа. SQL предлагает решение в стиле "есть большой, хороший комбайн, с помощью которого нужно научиться "готовить". Необходимо ввести там три (условно) правила.

Как это реализовано у нас в компании? Мы не используем джойны, стараемся не использовать ложные запросы и хранимые процедуры. Все вместе это позволяет нам худо-бедно обслуживать, по-моему. семь миллионов наших пользователей в день заходящих.

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

Реплика из зала: Можно использовать несколько NoSQL-решений для решения конкретных задач. Они будут быстрее работать, чем...

Сергей Аверин: Можно. Но разработчики стоят очень дорого. Представьте себе: наняли разработчика, который знает пять разных NoSQL-баз данных, готов их сравнивать между собой, знает все плюсы и минусы. Какую часть Кап-теоремы они реализуют и т.п. Когда у вас стоит задача нанять сто сорок офисных программистов, это сделать не реально.

Реплика из зала: Вы сейчас нарушаете первый же пункт, забегая вперед.

Сергей Аверин: Мы – большая компания.

Реплика из зала: Ну, так, а вы для кого доклад делали? Для больших компаний, которые хотят стать еще больше?

Сергей Аверин: В начале доклада что написано?

Реплика из зала: "Семь советов стартапам".

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

Реплика из зала: К вопросу о будущем. Стоит ли использовать базы данных, не располагающихся в открытом доступе? "DB2", "Informix", "Oracle"...

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

Понимаете, в чем дело… В стартапе всегда есть одна болезнь. Она называется: "Мы решим важную техническую задачу, а бизнес-задачами заниматься не будем". Тогда сделайте проект, выложите его в открытом доступе и разместите на "Github". Если вы не занимаетесь бизнесом, лучше не рискуйте. У вас могут однажды закончиться деньги, если будете платить за базу.

Мы в "Badoo" (это большая компания) используем дорогую базу данных "VectorWise". Она используется для того, чтобы считать статистику по очень большому количеству статистических данных для проведения маркетинговых исследований и отчетов в лондонском офисе. Все остальное делается на MySQL. Еще мы использовали "Redis", часто используем "Handler Socket". Также остались "крохи" "MongoDB".

Но у нас паттерн NoSQL всегда следующий: перенеси работающую задачу на него и если будет работать лучше, то оставить. Так получилось, что "Redis", как и "MongoDB", у нас не остался, в отличие от "Handler Socket". Правда с с ним проблем было столько, что я месяца три работал на библиотекой. Мы написали для него свой "клиент".

Реплика из зала: Что вы скажете о базе данных PostgreSQL?

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

А PostgreSQL не рассчитана на такие дела. Она создает новый процесс на каждое соединение. Получается, что большое количество соединений нельзя открыть.

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

Реплика из зала: В "Badoo" используется MySQL?

Сергей Аверин: Сейчас используется Percona-сервер. Но где-то остался и MySQL.

Реплика из зала: Есть свои задачи, которые приходится решать. Как вы решаете задачу с необходимостью изменения схемы базы данных?

Сергей Аверин: Мы делаем код такой, чтобы он был совместим с обоими из предыдущей версии, схемы и со следующей версией схемы. Затем, есть админы, готовый функционал, который эти схемы меняет в шардах. В несколько потоков, но по очереди. Поскольку у нас двести серверов, которые хранят юзерские данные, невозможно взять и сделать "alter table" на всех – повиснет. Поэтому это делается вечером, когда нет трафика.

Схема меняется после того, как был выложен код, который умеет работать со старой и новой схемой. Стараемся делать вот так. В 99,9% случаев весь функционал у нас делается вот так. Есть возможность задетектить обновленные. База данных обновилась, или "демон", которым мы коннектимся, обновился. Используется какая-то другая ветка кода.

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

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

Сергей Аверин: Пока не измеряешь, ты не контролируешь процесс. Нужно в какой-то момент начать измерять ("Capacity" серверов, загрузку LA и все такое). Про это у нас был отличный доклад на прошлом РИТе.

Есть прекрасная книжка, называется "Искусство масштабирования". Искусство "Capacity planning". Советую ее прочитать.

Реплика из зала: Если я правильно понял, у вас собственная реализация репликации MySQL-серверов.

Сергей Аверин: Да.

Реплика из зала: Почему вы отказались от стандартной, в чем преимущество вашей собственной реализации?

Сергей Аверин: Было две причины. На тот момент каких-то нужных свойств не было, когда все это проектировалось (2006-й год). Во-вторых, нужна была репликация с дата-центра "Worldness". Разная репликация между дата-центрами - разная репликация на площадке. Поэтому так исторически сложилось, что она была сделана скриптами на PHP. Для этого есть пустые сервера, которые хранят репликационные данные. Если они закончатся, таблицы опять опустеют.

Реплика из зала: Что вы можете сказать насчет используемой платформы?

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

Реплика из зала: Я хотел бы вернуться к теме джойнов. Вы сказали, это и добро, и зло одновременно. У вас джойнов в проекте "Badoo" нет принципиально вообще или они используются только в новом коде?

Сергей Аверин: Их принципиально нет с самого первого дня проекта. Была сильная команда, которая до этого делала "Mamba" и знала много подводных камней. На самом деле, джойны есть, но в 0,000001 случае из ста – там, где нет высоких нагрузок.

Реплика из зала: А что это за случай?

Сергей Аверин: Это когда нужно "джойнить" с четырьмя рядами. Например, у вас есть множество сообщений, вам нужно выбрать последние сто и выбрать название папки, в которой он лежит. А этих папок у вас всего четыре: "Входящие", "Исходящие", "Удаленные" и "До свидания". Поэтому в таком случае мы используем джойны. Их очень мало.

Каждому разработчику всегда нужно соизмерять объемы.

Реплика из зала: Еще про хранение процедур вы рассказали интересно.

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

Реплика из зала: Как используется транзакционность?

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

profyclub.ru

Научные базы данных в интернете

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

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

Впрочем, не все так безнадежно, ведь существует достаточно большое количество сетевых ресурсов, на которые спокойно можно ссылаться, цитировать в научных трудах, использовать для учебной или профессиональной деятельности. Достоверность представляемых интернет-ресурсов можно определить также с помощью ряда серьезных специализированных сайтов по вопросам информационного обеспечения, где публикуются списки линков либо некие таблицы достоверности (www.harrassowitz.de/top_resources/ejresguide.html, www.istl.org).

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

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

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

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

Существуют несколько крупных информационных систем, предлагающих доступ к реферативно-библиографическим и полнотекстовым БД: STN International, Lexis-Nexis (www.lexisnexis.com), Dialog (www.dialog.com). По сути, это системы-интеграторы, которые объединяют большое количество разномастных БД в рамках единого поискового интерфейса и языка информационных записей. Структура таких информационных гигантов примерно одинакова, поэтому достаточно подробно остановиться только на одной системе - международном информационном концерне STN International (все остальные созданы по тому же принципу).

STN International (www.stn-international.de) существует с середины 80-х гг., объединяя более 200 БД по всем отраслям науки и технологий. Ряд БД являются ретроспективными, представляя публикации, начиная еще с XVII-XIX веков (!). БД системы STN создаются более чем сотней научно-исследовательских и информационно-аналитических учреждений, организаций, издательств. В общем, через БД STN International представлены публикации примерно 50 тыс. периодических изданий, а также патентные и научно-технические архивы ряда крупнейших национальных и международных организаций. Система предлагает и реферативно-библиографические, и полнотекстовые БД.

Среди наиболее значительных БД, входящих в систему STN International, надо отметить следующие (кстати, практически все из них входят также и в систему DIALOG):

SciSearch - универсальная реферативно-библиографическая БД, принадлежащая американской ISI-Thomson Scientific, охватывает все фундаментальные разделы науки и техники, включает описания более 20 млн. статей из 5,6 тыс. научных журналов, начиная с 1974 г., используется поисковый механизм Citation Index.

PROMT - полнотекстовая БД, генерируемая американским издательским концерном Gale Group, включает публикации из 2,5 тыс. журналов, начиная с 1978 г. Объем информационного массива - более 10 млн. документов по вопросам науки, промышленности, экономики и бизнеса.

INSPEC - библиографическая БД, генерируемая британским Institution of Electrical Engineers, включает около 8 млн. библиографических описаний статей из 7,5 тыс. журналов в области физики, электроники и компьютерных технологий, ведется с 1969 г.

CA-Plus - универсальная реферативно-библиографическая БД по вопросам химии и химических технологий, генерируется Chemical Abstracts Service (США), описывает более 22 млн. документов всех видов, изданных в 150 странах с 1907 г., среди которых статьи из более чем 8 тыс. журналов. В БД используются специализированные алгоритмы и методы информационного поиска, в т.ч. механизм Citation Index.

EMBASE - универсальная реферативно-библиографическая БД по вопросам биомедицины и фармакологии, включает описания более 9 млн. документов из 4 тыс. периодических изданий из 70 стран, начиная с 1974 г.

AGRICOLA - универсальная реферативно-библиографическая БД по вопросам сельского хозяйства и пищевых технологий, создана и ведется Национальной сельскохозяйственной библиотекой и Министерством сельского хозяйства США. База данных включает описания 3,7 млн. документов, находящихся в фондах Национальной сельскохозяйственной библиотеки США с 1970 г.

AEROSPACE - реферативно-библиографическая БД по вопросам авиационных и космических технологий, генерируется американской компанией CSA-Aerospace Access, включает описания 2,3 млн. документов разных видов, начиная с 1962 г., которые были опубликованы в более чем 100 странах мира.

JICST-Plus - универсальная реферативно-библиографическая БД по всем разделам науки и техники, разработана японской корпорацией The Japan Science and Technology Corporation, включает описания более чем 4,5 млн. научных документов и публикаций, начиная с 1985 г., опубликованных в Японии.

STANDARDS - специализированная БД по стандартам и нормативам ISO и национальных систем стандартизации Германии, Франции, Австрии, Швейцарии, США и Японии. База включает более 500 тыс. рефератов стандартов и нормативных документов, поддерживается German Information Center for Technical Rules.

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

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

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

Майлз Vornet,[email protected]

www.kv.by

Системы управления базами данных

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

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

Основные функции субд

1. управление данными во внешней памяти. Методы и алгоритмы управления данными являются «внутренним делом» СУБД. Качество реализации этой функции наиболее сильно влияет на эффективность работы АИС, например, с огромными БД, со сложными запросами, большим объемом обработки данных.

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

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

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

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

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

• плоские или классические транзакции;

• цепочечные транзакции;

• вложенные транзакции.

Плоские или традиционные транзакции характеризуются четырьмя классическими свойствами: атомарности, согласованности, изолированности, долговечности (прочности) — ACID (Atomicity, Consistency, Isolation, Durability). Иногда традиционные транзакции называют ACID-транзакциями. Упомянутые выше свойства означают следующее:

• Свойство атомарности (Atomicity) выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе.

• Свойство согласованности (Consistency) гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое - транзакция не разрушает взаимной согласованности данных.

• Свойство изолированности (Isolation) означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно.

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

4. Ведение журнала изменений в бд

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

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

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

studfiles.net

---

• 
  Журнал проведения инструктажа с родителями по пдд в детском саду
• 
  Журнал ознакомления с локальными нормативными актами при приеме на работу
• 
  Отрывки из журнала маши одоевский краткое содержание для читательского дневника
• 
  Форма журнала учета проверки знаний правил работы в электроустановках 2017
• 
  Статья из журнала на английском языке с переводом 5000 знаков
• 
  Статья на английском языке из журнала по экономике с переводом
• 
  Журнал учета выдачи нарядов допусков на выполнение работ повышенной опасности
• 
  Какой журнал попал в 2011 году в книгу рекордов гиннеса
• 
  Какой журнал в 2011 году попал в книгу рекордов гиннеса
• 
  Заполнять журнал учета присвоения 1 группы по электробезопасности как заполнять
• 
  Список величайших исполнителей всех времен по версии журнала rolling stone