Оптимизация доступа к данным с использованием технологии JSon

int bytesAvailable = inStream.available();

readedBytes = new byte[bytesAvailable];

inStream.read(readedBytes);

}

// do some work with readedBytes

// …

}catch(IOException e){

/* IOException будет брошено, когда поток inStream либо связанный с ним

PipedOutputStream будет закрыт, после чего будет произведена попытка считывания

из inStream */

System.out.println("работа с потоком inStream завершена");

}

Так как с объектом inStream одновременно могут работать несколько потоков выполнения, блок synchronized(inStream){…} гарантирует, что во время между вызовами inStream.available() и inStream.read(…), ни в каком другом потоке выполнения не будет произведено считывание из inStream. Поэтому вызов inStream.read(readedBytes) не приведет к блокировке, и все данные, готовые к считыванию - будут считаны.

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

Если для каких-либо целей, мы хотим считать строку - объект String как набор byte, то можем воспользоваться классом StringBufferInputStream. Например, если мы уже используем потоки, а некоторые данные получили в виде строки, можно организовать считывание данных из нее через единый интерфейс. При создании объекта StringBufferInputStream необходимо конструктору передать объект String. Данные, возвращаемые методом read(), будут браться именно из этого объекта String. При этом символы будут преобразовываться в байты не совсем точно - будут учитываться только младшие 8 бит у символа(в то время как тип char состоит их 2-х байт).

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

При создании объекта этого класса в конструктор в качестве параметров передаются объекты InputStream - либо два экземпляра либо Enumeration из них. Когда вызывается метод read(), SequenceInputStream пытается считать байт из текущего входного потока. Если в нем больше нет данных(считанное из него значение равно -1), у этого входного потока вызывается метод close(), и следующий входной поток становится текущим. Так до тех пор, пока последний входной поток не станет текущим, и из него не будут считаны все данные. Тогда, если при считывании обнаруживается, что в текущем входном потоке нет больше данных, и больше нет входных потоков SequenceInputStream возвращет -1, то есть объявляет, что данных больше нет. SequenceInputStream автоматически вызывает вызов метода close() у входных потоков, у которых достигнут конец. Вызов метода close() у SequenceeInputStream закрывает этот поток, предварительно закрыв все содержащиеся в нем входные потоки. Пример:

FileInputStream inFile1 = null;

FileInputStream inFile2 = null;

SequenceInputStream sequenceStream = null;

FileOutputStream outFile = null;

try {

inFile1 = new FileInputStream("file1.txt");

inFile2 = new FileInputStream("file2.txt");

sequenceStream = new SequenceInputStream(inFile1, inFile2);

outFile = new FileOutputStream("file3.txt");

int readedByte = sequenceStream.read();

while(readedByte!=-1){

outFile.write(readedByte);

readedByte = sequenceStream.read();

}

} catch (IOException e) {

System.out.println("IOException: " + e.toString());

} finally {

try{sequenceStream.close();}catch(IOException e){};

try{outFile.close();}catch(IOException e){};

}

В результате выполнения этого примера в файл file3.txt будет записано содержимое файлов file1.txt и file2.txt - сначала полностью file1.txt и потом file2.txt. Закрытие потоков производится в блоке finally. При этом, так как при вызове метода close() может возникнуть IOException, то каждый такой вызов должен быть взят в try-catch блок. Причем в отдельный try-catch блок взят каждый вызов метода close() - для того, что бы все потоки были закрыты независимо от возникновения исключений при закрытии других потоков. При этом нет необходимости закрывать потоки inFile1 и inFile2 - они будут автоматически закрыты при использовании в sequnceStream - либо когда в них закончатся данные, либо при вызове у sequencecStream метода close().

Объект SequenceInputStream можно было создать и другим способом: сначала получить объект Enumeration, содержащий все потоки, и передать этот объект Enumeration в конструктор SequenceInputStream:

Vector vector = new Vector();

vector.add(new StringBufferInputStream("Begin file1\n"));

vector.add(new FileInputStream("file1.txt"));

vector.add(new StringBufferInputStream("\nEnd of file1, begin file2\n"));

vector.add(new FileInputStream("file2.txt"));

vector.add(new StringBufferInputStream("\nEnd of file2"));

Enumeration enum = vector.elements();

sequenceStream = new SequenceInputStream(enum);

Если заменить в предыдущем примере инициализацию sequenceeStream на приведенную здесь, то в файл file3.txt кроме содержимого файлов file1.txt и file2.txt будут записаны еще и три строки - одна в начале файла, одна между содержимым файлов file1.txt и file2.txt и еще одна дописана в конец file3.txt.

Задачи, возникающие при вводе/выводе крайне разнообразны - этот может быть считывание байтов из файлов, объектов из файлов, объектов из массивов, буферизованное считывание строк из массивов. В такой ситуации решение путем простого наследования приводит к возникновению слишком большого числа подклассов. Решение же, когда требуется совмещение нескольких свойств, высокоэффективно в виде надстроек. (В ООП этот паттерн называется адаптер.) Надстройки - наложение дополнительных объектов для получения новых свойств и функций. Таким образом, необходимо создать несколько дополнительных объектов - адаптеров к классам ввода/вывода. В java.io их еще называют фильтрами. При этом надстройка-фильтр, включает в себя интерфейс объекта, на который надстраивается, и поэтому может быть в свою очередь дополнительно быть надстроена.

В java.io интерфейс для таких надстроек ввода/вывода предоставляют классы FilterInputStream (для входных потоков) и FilterOutputStream (для выходных потоков). Эти классы унаследованы от основных базовых классов ввода/вывода - InputStream и OutputStream соответственно. Конструкторы этих классов принимают в качестве параметра объект InputStream и имеют модификатор доступа protected. Сами же эти классы являются базовыми для надстроек. Поэтому только наследники могут вызывать его(при их создании), передавая переданный им поток. Таким образом обеспечивается некоторый общий интерфейс для надстраиваемых объектов.

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

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

BufferedInputStream - содержит в себе массив байт, который служит буфером для считываемых данных. То есть, когда байты из потока считываются (вызов метода read()) либо пропускаются(метод skip()), сначала перезаписывается этот буферный массив, при этом считываются сразу много байт за раз. Так же класс BufferedInputStream добавляет поддержку методов mark() и reset(). Эти методы определены еще в классе InputStream, но их реализация по умолчанию бросает исключение IOException. Метод mark() запоминает точку во входном потоке и метод reset() приводит к тому, что все байты, считанные после наиболее позднего вызова метода mark(), будут считаны заново, прежде чем новые байты будут считываться из содержащегося входного потока.

BufferedOutputStream - при использовании объекта этого класса, запись производится без необходимости обращения к устройству ввода/вывода при записи каждого байта. Сначала данные записываются во внутренний буфер. Непосредственное обращение к устройству вывода и, соответственно, запись в него произойдет, когда буфер будет полностью заполнен. Освобождение буфера с записью байт на устройство вывода можно обеспечить и непосредственно - вызовом метода flush(). Так же буфер будет освобожден непосредственно перед закрытием потока (вызов метода close()). При вызове этого метода также будет закрыт и поток, над которым буфер надстроен.

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

try {

String fileName = "d:\\file1";

InputStream inStream = null;

OutputStream outStream = null;

//Записать в файл некоторое количество байт

long timeStart = System.currentTimeMillis();

outStream = new FileOutputStream(fileName);

outStream = new BufferedOutputStream(outStream);

for (int i = 1000000; --i >= 0; ) {

outStream.write(i);

}

long time = System.currentTimeMillis() - timeStart;

System.out.println("Writing durates: " + time + " millisec");

outStream.close();

// Определить время считывания без буферизации

timeStart = System.currentTimeMillis();

inStream = new FileInputStream(fileName);

while (inStream.read() != -1) {

}

time = System.currentTimeMillis() - timeStart;

inStream.close();

System.out.println("Direct read durates " + (time) + " millisec");

timeStart = System.currentTimeMillis();

inStream = new FileInputStream(fileName);

inStream = new BufferedInputStream(inStream);

while (inStream.read() != -1) {

}

time = System.currentTimeMillis() - timeStart;

inStream.close();

System.out.println("Buffered read durates " + (time) + " millisec");

} catch (IOException e) {

pr("IOException: " + e.toString());

e.printStackTrace();

}

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

Writing durates: 359 millisec

Direct read durates 6546 millisec

Buffered read durates 250 millisec

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

Классы BufferedInputStream и BufferedOutputStream добавляют только внутреннюю логику по обработке запросов, они не добавляют никаких дополнительных методов. Следующие два фильтра как раз добавляют некоторые дополнительные возможности при работе с потоками. Однако, первый из них - LineNumberInputStream объявлен deprecated начиная с версии jdk 1.1, и использовать его не рекомендуется.

LineNumberInputStream. Расширяет функциональность InputStream тем, что дополнительно производит подсчет, сколько строк было считано из потока. Номер строки, на которой в данный момент происходит чтение можно узнать вызовом метода getLineNumber(). Так же можно и пеерейти к определенной строке, вызовом метода setLineNumber(int lineNumber).

Под строкой при этом понимается набор байт, оканчивающийся либо '\n' либо '\r' либо их комбинацией '\r\n' именно в этой последовательности. Аналогичный класс для OutputFilter - отсутствует.

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

Следующий класс также является deprecated, и его не рекомендуется применять при написании программ, работающих с различными кодировками. Однако он продолжает активно использоваться в силу исторических причин, так как статические поля out и err класса System ссылаются на объекты именно этого класса, и, поэтому его необходимо знать.

Класс PrintStream используется для конвертации и записи строк в байтовый поток. В классе PrintStream определен метод print(), принимающий различные примитивные типы java а так же Object. При вызове этих методов передаваемые данные будут сначала превращены в строку вызовом метода String.valueOf(), после чего записаны в поток. То есть, в поток данные будут записаны в представлении, удобном для прочтения человеком. При этом, даже если возникает исключение, то оно обрабатывается внутри метода print и дальше НЕ кидается. При записи строки используется кодировка, определяемая из настроек системы, где выполняется программа. При этом PrintStream не поддерживает Unicode. Вообще же для работы с текстовыми данными следует использовать Writer`ы. Аналогичный класс для InputFilter - отсутствует.

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

До сих пор речь шла только о считывании и записи в поток данных в виде byte. Для работы с другими примитивными типами данных java, определены интерфейсы DataInput и DataOutput, и существующие их реализации - классы-фильтры DataInputStream и DataOutputStream..

Интерфейсы DataInput и DataOutput определяют, а классы DataInputStream и DataOutputStream, соответственно реализуют, методы считывания и записи всех примитивных типов данных. При этом происходит конвертация этих данных в byte и обратно. При этом в поток будут записаны байты, а ответственность за восстановление данных лежит только на разработчике - нужно считывать данные в виде тех же типов, в той же последовательности, как и производилась запись. То есть, можно, конечно, записать несколько раз int или long, а потом считывать их как short или что-нибудь еще - считывание произойдет корректно и никаких предупреждений о возникшей ошибке не возникнет, но результат будет соответствующий - значения, которые никогда не записывались.



3. Рефакторинг базы данных ООО “Социальная инноватика” в рамках осуществления оптимизации доступа к данным

3.1 JSON база данных

При разработке web приложений, часто возникает потребность в хранении определённых настроек или временных данных. Обычно, для этого используются или файлы, или базы данных. Если это база данных, то хранить в базе таблицу с одной строкой, как чаще всего это бывает, не очень удачный вариант. Для этого чаще используются config файлы определенных форматов (*.php, *.ini, *.xml, *.json).

Использование именно формата json удобно тем, что информация в данном формате -- это Javascript массивы и объекты, описанные выше, к которым легко можно получить доступ с клиентской части web приложения.

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

Быстродействие такой системы хранения данных, особенно при использовании методов update и insert, очень сильно зависит от количества записей в одной таблице. Выборка данных из таблиц происходит достаточно быстро. Использование такого метода хранения информации хорошо подходит для хранения различных настроек приложений и временных данных. Как было сказано выше, в этом так же есть большой плюс из-за того, что к любой информации, хранимой в данном виде, можно получить доступ с клиентской части приложения. Если подробнее, то например с помощью JQuery метода $.getJSON.

3.2 Доступ к документным данным в ООО “Социальная инноватика”

В рамках осуществления оптимизации доступа к данным с использованием технологии JSON был проведен рефакторинг существующей схемы базы данных предприятия ООО “Социальная инноватика”. Данная система реализует документооборот организации. На рисунке 3.1 представлена схема базы данных до рефакторинга. На данном рисунке представлена не вся схема базы данных предприятия, а только та ее часть, которая связана с дальнейшим рефакторингом.

Рис 3.1 - Схема базы данных

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

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

Унификация хранения структуры документа.

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

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

Рис 3.2 - Интерфейс приложения PgAdmin

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

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

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

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

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

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

Сохранение существующей системы управления базами данных (в текущей реализации это PostgreSQL).

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

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

Сохранение приемлемой скорости работы базы данных даже отрефакторенной части базы данных.

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

Анализ путей решения проблем.

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

Хранение документов в сериализованном формате. В качестве формата для хранения можно использовать такие форматы, как JSON (JavaScript Object Notation), XML (eXtensible Markup Language) или другие стандартизированные в сообществе форматы. Однако у данного подхода есть некоторые ограничения. В частности, при таком подходе неудобно производить фильтрацию по списку пользователей. При такой схеме фильтрация будет происходить полностью на клиентском приложении. Для поиска необходимо будет извлечь все записи из интересующей таблицы, десериализовать и провести поиск уже по десериализованным данным. Очевидно, что данный подход неудобен и создает лишнюю нагрузку на базу данных. Роль самой базы данных в данном случае очень сильно снижается

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

Основные возможности данной системы:

Документоориентированное хранение (JSON-подобная схема данных).

Javascript как язык для формирования запросов.

Динамические запросы.

Поддержка индексов.

Профилирование запросов.

Атомарная операция «Нашел и обновил».

Эффективное хранение двоичных данных больших объёмов, например, фото и видео.

Журналирование операций, модифицирующих данные в базе данных.

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

Может работать в соответствии с парадигмой MapReduce.

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

Основным плюсом данной СУБД является хранение записей в таблице (или в терминах MongoDB “коллекции”) данных разной структуры. Данному требованию удовлетворяют все документы и это является краеугольным камнем всей системы.

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

Использование новых возможностей СУБД PostgreSQL.

Начиная с PostgreSQL 9.5 добавлен новый тип полей jsonb. Он позволяет хранить внутри себя строку json формата и проводить эффективный поиск по ним. В частности на поля внутри json можно добавлять индексы а также проводить поиск по полям произвольной вложенности. Небольшим недостатком данной схемы является то, что на момент начала работы над проектом версия PostgreSQL на предприятии была 9.3. Поэтому, я совместно с техническими специалистами ООО “Социальная инноватика” провел сервисные работы по обновлению системы управления базы данных, а также миграцию данных со старой версии на новую. Данный вариант оказался самым приемлемым, однако оставались вопросы по производительности, поэтому окончательное решение об использовании jsonb в проекте можно было принять только после нагрузочного тестирования базы данных.

3.3 Рефакторинг схемы базы данных

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

Рис 3.3 - Итоговая схема базы данных

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

{

"date": "20.01.2017",

"document_number": "234",

"emplyees": [

{

"employee": "Иванов Иван Иванович",

"start_date": "10.07.2017",

"end_date": "03.08.2017"

},

{

"employee": "Сидоров Петр Семенович",

"start_date": "10.02.2017",

"end_date": "03.03.2017"

}

]

}

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

Поиск по документам может осуществляться таким образом

SELECT * FROM documents WHERE data @> '{"data":”10.05.2016”}';

В данном запросе мы выбираем все документы позднее даты 10.05.2016.

3.4 Тестирование производительности

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

Для начала проводился тест на вставку данных. Вставлялось 10, 100, 1000, 10000 и 100000 документов соответственно и замерялась общая скорость выполнения. Во втором варианте в json не учитывалась скорость сериализации документа, т.к по умолчанию предполагается, что клиентские машины позволяют делать сериализацию в json за сколь угодно малое время. Все документы были разного назначения. У всех графиков по оси абсцисс отложены количество документов, по оси ординат - время в секундах на выполнение вставки x документов.



Рис 3.4 - Тестирование запросов на вставку

Рис 3.5 - Тестирование запросов на вставку

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



Заключение

В результате бакалаврской работы был проведен рефакторинг базы данных предприятия ООО “Социальная инноватика”. В реляционной схеме хранения были добавлены некоторые аспекты, присущие NoSQL системам хранения данных.

Были решены следующие задачи:

изучены виды оптимизации доступа к документным данным,

изучены возможности применения формата JSON,

проанализирована существующую базу данных в ООО «Социальная инноватика»,

проведен рефакторинг существующей базы данных предприятия ООО “Социальная инноватика”.

В общем и целом, повысилась простота доступа к данным и упрощение поддержки системы ценой несущественного падения производительности. Данный результат признан положительным и внедрен в ООО “Социальная инноватика”.



Список использованных источников

1. Эккель Б. Философия Java. Библиотека программиста [Текст]/Б. Эккель - 4-е изд. - СПб.: Питер, 2009. - 640 с.

2. Шилдт Г. Java. Полное руководство [Текст]/Г. Шилдт - 8-е изд.: пер. с англ. - М.: ООО «И.Д. Вильямс», 2012. - 1104 с.

3. Спецификация языка Java [Электронный ресурс]/2014.- Режим доступа: http://java.sun.com/docs/books/jls, свободный. - Загл. с экрана

4. Введение в JSON [Электронный ресурс]/2016.- Режим доступа: http://www.json.org/json-ru.html свободный. - Загл. с экрана

5. JSON [Электронный ресурс]/2016.- Режим доступа: https://ru.wikipedia.org/wiki/JSON свободный. - Загл. с экрана

6. Спецификация виртуальной машины Java [Электронный ресурс]/2014- Режим доступа: http://java.sun.com/docs/books/jvms/, свободный. - Загл. с экрана

7. Многопоточность в среде Java [Электронный ресурс]/2014.- Режим доступа: https://software.intel.com/ru-ru/articles/multi-threading-in-a-java-environment, свободный. - Загл. с экрана

8. Спецификация java.util.Concurrency [Электронный ресурс]/2014.- Режим доступа: http://java.sun.com/javase/6/docs/api/java/util/ Concurrency.html, свободный. - Загл. с экрана

9. Модульное тестирование с JUnit [Электронный ресурс]/2014.- Режим доступа: http://www.quizful.net/post/jUnit4_common_information, свободный. - Загл. с экрана

10. Спецификация java.lang.Thread [Электронный ресурс]/2014.- Режим доступа: http://java.sun.com/javase/6/docs/api/java/lang/Thread.html, свободный. - Загл. с экрана

11 Вирт, Н. Алгоритмы и структуры данных. Пер. с англ. [Текст]/ Н.Вирт. - СПб: Невский Диалект, 2008 г. - 352 с.



Приложение

Презентационный материал

Размещено на Allbest.ru

...