с реляционными базами данных 1 глава




BDE

BDE представляет собой совокупность динамических библиотек и драйверов, обеспечивающих доступ к данным. Процессор BDE должен устанавливаться на всех компьютерах, на которых выполняются Delphi-приложения, осуществляю­щие работу с БД. Приложение через BDE передает запрос к базе данных, а об­ратно получает требуемые данные. Механизм BDE до 7-й версии системы Del-


Глава 1. Основные понятия баз данных


11


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

ADO

Механизм ADO доступа к информации базы данных является стандартом фир­мы Microsoft. Использование этой технологии подразумевает использование на­страиваемых провайдеров данных. Технология ADO обеспечивает универсаль­ный механизм доступа из приложений к информации источников данных. Эта технология основана на стандартных интерфейсах СОМ, являющихся систем­ным механизмом Windows. Это позволяет удобно распространять приложения баз данных без вспомогательных библиотек.

DbExpress

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

Варианты архитектуры для BDE

Здесь мы рассмотрим различные варианты архитектуры информационной сис­темы на примере технологии BDE. Варианты архитектуры для других техноло­гий доступа к данным рассмотрим позже при непосредственном их описании.

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


12


Часть I. Основы работы с базами данных


Компьютер пользователя

Рис. 1.1. Локальная архитектура

Для доступа к локальной БД процессор баз данных BDE использует стандарт­ные драйверы, которые позволяют работать с форматами БД dBase, Paradox, FoxPro, а также с текстовыми файлами.

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

При работе с данными на каждом пользовательском компьютере сети использу­ется локальная копия БД. Эта копия периодически обновляется данными, со­держащимися в БД на сервере.

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


Глава 1. Основные понятия баз данных


13


Однако архитектура "файл-сервер" имеет и существенные недостатки.

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

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

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

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

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

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

□ Снижение нагрузки на сеть, поскольку теперь в ней циркулирует только нужная информация.

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



Часть I. Основы работы с базами данных


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

Для реализации архитектуры "клиент-сервер" обычно используются много­пользовательские СУБД, например, Oracle или Microsoft SQL Server. Подобные СУБД также называют промышленными, т. к. они позволяют создать информаци­онную систему организации или предприятия с большим числом пользователей. Промышленные СУБД являются сложными системами и требуют мощной вычислительной техники и соответствующего обслуживания. Обслуживание вы­полняет специалист (или группа специалистов), называемый системным админи­стратором БД (администратором). Основные задачи системного администратора:

□ защита БД;

□ поддержание целостности БД;

□ обучение и подготовка пользователей;

□ загрузка данных из других БД;

□ тестирование данных;

□ резервное копирование и восстановление;

□ внесение изменений в информационную систему.

Доступ Delphi-приложения к промышленным СУБД осуществляется через драй­веры SQL-Links. Отметим, что при работе с "родной" для Delphi СУБД InterBase можно обойтись без драйверов SQL-Links.

Описанная архитектура является двухуровневой (уровень приложения-клиента и уровень сервера БД). Клиентское приложение также называют сильным, или "толстым", клиентом. Дальнейшее развитие данной архитектуры привело к по­явлению трехуровневого варианта архитектуры "клиент-сервер" (приложение-клиент, сервер приложений и сервер БД) (рис. 1.4).


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

Основные достоинства трехуровневой архитектуры "клиент-сервер" состоят в следующем:

□ разгрузка сервера от выполнения части операций, перенесенных на сервер приложений;

□ уменьшение размера клиентских приложений за счет разгрузки их от лишне­го кода;

□ единое поведение всех клиентов;

□ упрощение настройки клиентов — при изменении общего кода сервера приложений автоматически изменяется поведение приложений-клиентов.

Напомним, что локальные приложения БД называют одноуровневыми, а клиент-серверные приложения БД — многоуровневыми.



Глава 2


Реляционные базы данных и средства работы с ними

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

Элементы реляционной базы данных

Реляционная база данных (БД) состоит из взаимосвязанных таблиц. Каждая таб­лица содержит информацию об объектах одного типа, а совокупность всех таблиц образует единую БД.

Таблицы баз данных

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

Для одной таблицы создается несколько файлов, содержащих данные, индексы, ключи и т. п. Главным из них является файл с данными, имя этого файла сов­падает с именем таблицы, которое задается при ее создании. В некотором смысле понятия таблицы и ее главного файла являются синонимами, при выбо­ре таблицы выбирается именно ее главный файл: для таблицы dBase это файл с расширением dbf, а для таблицы Paradox — файл с расширением db. Имена ос­тальных файлов таблицы назначаются автоматически — все файлы имеют оди­наковые имена, совпадающие с именами таблиц, и разные расширения, указы­вающие на содержимое соответствующего файла. Расширения файлов приведены ниже в данной главе в разд. "Таблицы форматов dBase и Paradox".


Глава 2. Реляционные базы данных и средства работы с ними


17


Каждая таблица БД состоит из строк и столбцов и предназначена для хранения данных об однотипных объектах информационной системы. Строка таблицы называется записью, столбец таблицы — полем (рис. 2.1). Каждое поле должно иметь уникальное в пределах таблицы имя.



 


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

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


J

Замечание

В зависимости от типа таблиц и системы разработки приложений может использо­ваться различная терминология. Например, в InterBase поле таблицы называется столбцом.

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

□ описание полей;

□ ключ;


18


Часть I. Основы работы с базами данных


П индексы;

□ ограничения на значения полей;

□ ограничения ссылочной целостности между таблицами;

□ пароли.

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

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

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

□ создание (определение структуры);

□ изменение структуры (реструктуризация);

□ переименование;

□ удаление.

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

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

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

(Замечание^

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

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


Глава 2. Реляционные базы данных и средства работы с ними


19


Ключи и индексы

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

□ однозначную идентификацию записей таблицы;

□ ускорение выполнения запросов к БД;

□ установление связи между отдельными таблицами БД;

□ использование ограничений ссылочной целостности.

Ключ также называют первичным ключом или первичным (главным) индексом.

Информация о ключе может храниться в отдельном файле или совместно с дан­ными таблицы. Например, в БД Paradox для этой цели используется отдельный файл (ключевой файл или файл главного индекса) с расширением рх. В БД Access вся информация содержится в одном общем файле с расширением mdb. Значения ключа располагаются в определенном порядке. Для каждого значения ключа имеется уникальная ссылка, указывающая на расположение соответст­вующей записи в таблице (в главном ее файле). Поэтому при поиске записи вы­полняется не последовательный просмотр всей таблицы, а прямой доступ к за­писи на основании упорядоченных значений ключа.

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

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

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

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

□ В состав ключа не могут входить поля некоторых типов, например, графиче­ское поле или поле комментария.

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


20


Часть I. Основы работы с базами данных


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

Удобным вариантом создания ключа будет использование для него поля соот­ветствующего типа, которое автоматически обеспечивает поддержку уникально­сти значений. Для таблиц Paradox таким является поле автоинкрементного типа, еще одним достоинством которого является небольшой размер (4 байта). В то же время в таблицах dBase и InterBase поле подобного типа отсутствует, и програм­мист должен обеспечивать уникальность значений ключа самостоятельно, на­пример, используя специальные генераторы.

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

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

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

Использование индекса обеспечивает:

□ увеличение скорости доступа к данным (поиска);

□ сортировку записей;

□ установление связи между отдельными таблицами БД;

□ использование ограничений ссылочной целостности.

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

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

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


Глава 2. Реляционные базы данных и средства работы с ними


21


Набор данных Query позволяет выполнить средствами SQL сортировку по лю­бым полям, однако и в этом случае для индексированных полей упорядочива­ние записей выполняется быстрее.

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

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

(Замечание^

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

Таким образом, использование ключей и индексов позволяет:

□ однозначно идентифицировать записи;

□ избегать дублирования значений в ключевых полях;

□ выполнять сортировку таблиц;

□ ускорять операции поиска в таблицах;

□ устанавливать связи между отдельными таблицами БД;

□ использовать ограничения ссылочной целостности.

Одной из основных задач БД является обеспечение быстрого доступа к данным (поиска данных). Время доступа к данным в значительной степени зависит от используемых для поиска данных методов и способов.

Методы и способы доступа к данным

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

□ последовательный;

□ прямой;

□ индексно-последовательный.

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



Часть I. Основы работы с базами данных


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

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

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

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

(_____ ЗамечаниеJ

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

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

П навигационный;

□ реляционный.

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


Глава 2. Реляционные базы данных и средства работы с ними


23


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

Способ доступа к данным выбирается программистом и зависит от средств дос­тупа к БД, используемых при разработке приложения. Например, в приложени­ях, создаваемых в Delphi, реализацию навигационного способа доступа можно осуществить посредством компонентов Table или Query, а реляционного — с помощью компонента Query.

Таким образом, методы доступа к данным определяются структурой БД, а спо­собы доступа — приложением.

Связь между таблицами

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

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

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



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-16 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: