Большинство IT-специалистов в ВУЗе слушали курс «Основы баз данных (ОБД)». Однако многие не придавали ему значение, кому-то не повезло с преподавателем, а кто-то не смог пробраться сквозь академические дебри реляционной теории.

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

Содержание

• Моделирование данных совместно с заказчиком
  • Участие заказчика в проектировании
    
  • Как превратить заказчика в единомышленника на период проектирования структуры данных
    
• Моделирование предметной области
  
• Инфологическая модель
  • Сущность
    
  • Нормализация
    
  • Атрибуты. Первичный и вторичный ключи
    
  • Внешний ключ. Классификация
    
  • Кратность связи «один-ко-многим». Опциональность связи
    
  • Атрибуты типа Список
    
  • Кратность связи «один-к-одному». Дискриминация
    • Отображение дискриминации в одну таблицу (инфоблок)
      
    • Отображение дискриминации в N таблиц
      
    • Отображение дискриминации в N+1 таблицу
      
    • Отображение дискриминации в 5 таблиц
      
  • Кратность связи «многие-ко-многим». Развязка
    
  • Каскадное удаление и проверка целостности данных
    

Как правило, сайт – это, в первую очередь, средство представления информации.

Информация, особенно в больших объёмах, нуждается в структурировании, классифицировании.

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

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

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

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

Моделирование данных совместно с заказчиком

Большинство IT-специалистов в ВУЗе слушали курс «Основы баз данных (ОБД)». Однако многие не придавали ему значение, кому-то не повезло с преподавателем, а кто-то не смог пробраться сквозь академические дебри реляционной теории.

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

Участие заказчика в проектировании

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

Да, бриф – это очень важно. Но с созданием брифа работа с заказчиком не заканчивается, а только начинается.

Предстоит сделать самое сложное – вместе с заказчиком построить инфологическую, а потом и даталогическую модели сайта (о них чуть ниже).

Умерьте свой оптимизм: вне зависимости от уровня вашей квалификации вы не создадите информационную архитектуру сайта без плотного участия заказчика. Это означает буквально следующее: вы вместе с заказчиком садитесь поудобнее около достаточно большого монитора (хотя бы 20 дюймов), запускаете MS Visio – и рисуете.

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

Разумеется, чтобы заказчик не заскучал, вы должны владеть Visio в совершенстве. Благо, для рисования ER-диаграмм не требуется слишком много навыков рисования (зато потребуется отличное знание реляционной теории). В данной главе мы рассмотрим её основы.

Согласны, убедить заказчика в необходимости совместного рисования ER-диаграммы ох как непросто. Считается, что в идеале от заказчика должно быть получено объёмистое ТЗ, где как раз и будут перечислены все сущности и связи. А уже по этому ТЗ проектировщик должен самостоятельно нарисовать ER. Осмелимся утверждать, что это неверно, и вот почему:

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

При проектировании традиционных приложений, связанных с использованием баз данных, обычно не возникает вопроса о необходимости создания ER-модели. К величайшему сожалению, в web-индустрии (включая сообщество Битрикс-разработчиков) с этим дела обстоят весьма печально. Возможно, это связано с тем, что web-программисты в гораздо большей степени «визуалы», тогда как традиционные программисты – в основном, «абстракционщики».

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

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

Нередко проектировщики всё же создают некоторое подобие ER-диаграммы. При этом они выносят на неё лишь самые основные сущности (то есть те, что заказчик, не являясь специалистом в этой области, отметил в ТЗ) и не удосуживаются отрисовать полностью все возможные атрибуты и связи. Мотивируют они это тем, что по мере работы над проектом диаграмма непрерывно будет изменяться.

Это утверждение абсолютно верно. Как сказал Антуан де Сент-Экзюпери, «достроенный город – мёртвый город». Проект – живой организм, и только по окончании проекта известны все требования – и от этого никуда не деться.

Однако если уже в самом начале потратить время и максимально точно определиться с тем, что же всё-таки планируется вынести на сайт, то потом этих переделок и новых требований будет существенно меньше. (Они будут, но это будет скорее обусловлено тем, что за время разработки бизнес заказчика меняется, а не тем, что в самом начале решили не расставлять все точки над i).

Итак, мы считаем, что для создания качественного сайта необходимо создание в самом начале полноценной ER-модели со всеми сущностями, атрибутами и связями. Именно она станет основой для проектирования структуры разделов («финальной» карты сайта), URL-адресов и даже макетов страниц.

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

Как утверждает Wikipedia, при создании IDEF-методологии основное внимание уделялось возможности эффективного обмена информацией между всеми специалистами. С широким применением этой связано возникновение основных идей понятия реинжиниринга бизнес-процессов.

Как превратить заказчика в единомышленника на период проектирования структуры данных

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

Следует, правда, понимать, что даже зная условные обозначения, заказчик вряд ли сможет самостоятельно прочитать диаграмму, если видит её впервые. Поэтому обязательно требуется зачитывать её заказчику, объясняя смысл каждой сущности и каждой связи.

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

На примере этих «кучек» вам будет нетрудно объяснить заказчику, что такое сущности:

• однотипные материалы на жаргоне сайтостроителей называются динамикой (потому что к этим материалам очень часто, динамично, добавляются новые материалы того же вида);
• каждая «кучка» однотипных материалов называется сущностью (не бойтесь в меру использовать узкоспециальную терминологию, но обязательно добивайтесь, чтобы заказчик её понимал);
• разнотипные материалы в отдельной стопке называются статикой (они описывают, как правило, основополагающие моменты деятельности компании, не зависящие от времени – поэтому они статичны, то есть меняются достаточно редко).

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

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

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

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

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

Что объединяет документы в каждой из «кучек» (извините, сущностей)?

• совокупность документов, лежащих в стопке, можно озаглавить существительным во множественном числе (например, «Книги», «Новости», «Издательства»);
• все документы в стопке имеют один и тот же набор атрибутов (например, у каждой книги есть автор, издательство, дата выпуска, аннотация и т.п.);
• документы в стопке можно отсортировать по какому-либо атрибуту (например, упорядочить книги по дате выпуска), либо отфильтровать (например, отобрать из стопки книги такого-то издательства).

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

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

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

Аналогично с автором книги – скорее всего, где-то существует картотека авторов (и нам не мешало бы ей обзавестись), и данная книга ссылается на одну из карточек.

Теперь представим, что нам надо расставить книги по полкам, и тут возникает другая проблема. В одном случае нам надо упорядочить по авторам (первая полка – все книги Иванова, вторая – Петрова, …), иногда – по издательствам (первая – «Эксмо», вторая – «Символ плюс», …), а иногда и по тематике (первая – «компьютерная литература», вторая – «психология», …) – для тематик нам тоже придётся завести картотеку. Каждый из этих вариантов называется классификацией, а если вариантов классификации много, то это называют многоаспектной классификацией (или таксономией). Каждый классификационный признак называют классификатором, а то, что мы классифицируем (в данном случае сущность «Книги») ­– объектом классификации (классифицируемой сущностью).

Классификатор тоже иногда может быть классифицирован. Так, например, авторов можно классифицировать по городам, в которых они проживают. В этом случае авторы уже выступают не в качестве классификатора, а в качестве объекта классификации. Классификатором же является картотека (сущность) «Города».

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

Связи имеют кратности. Так, обычно связь между сущностью-классификатором и сущностью-объектом классификации имеет кратность «один-ко-многим», например:

• у одного автора может быть много книг;
• в одном городе может жить много авторов.

Слово «может» в данном случае означает, что даже если автор написал только одну книгу, то, в принципе, мы исходим из того, что он мог написать несколько книг, и «одна» – это частный случай «нескольких».

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

Моделирование предметной области

Одна из основных задач при проектировании сайта – это моделирование предметной области заказчика.

Wikipedia определяет понятие модели следующим образом.

Однако в этой главе мы будем рассматривать моделирование не с академической, а с практической стороны, предполагая, что модель создаётся именно для сайта на платформе «1С-Битрикс» (поэтому многое будет опущено, а многое пересказано своими словами). Академический вариант можно найти, например, на Citforum.

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

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

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

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

В данной работе мы используем нотацию IDEF1x для представления обеих моделей. Эту нотацию очень удобно использовать при рисовании в Microsoft Visio.

При создании нового файла обязательно надпишите прямо на листе следующие параметры (см. пример в приложении):

• название проекта;
• тип модели (инфологическая или даталогическая: внешне они очень похожи);
• дату и время последнего изменения (Visio может автоматически обновлять это поле: правая клавиша по тексту, Insert Field, Date/Time, Last Edit Date/Time);
• основные условные обозначения стандарта IDEF1x.

Инфологическая модель

Сущность

Поясним смысл словосочетания «однотипные объекты». Так, каждая сущность должна иметь имя – существительное во множественном числе – достаточно широкое понятие, чтобы охарактеризовать все входящие в неё объекты, но достаточно узкое, чтобы исключить вхождение в эту сущность посторонних объектов. При этом каждый элемент, входящий в сущность, называется тем же существительным, но в единственном числе.

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

В IDEF1x сущность обозначается прямоугольником, сверху которого подписано имя сущности – существительное во множественном числе.

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

Нормализация

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

Нормализация предполагает последовательное приведение структуры данных к нормальным формам (NF). Их мы рассмотрим далее.

Цель нормализации – создание структуры данных, при которой:

• все данные не противоречат друг другу;
• исключена избыточность (все элементы данных вводятся и хранятся только в единственном экземпляре).

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

Нормализация – это некий идеал, к которому следует стремиться, но которого не всегда стоит достигать.

Атрибуты. Первичный и вторичный ключи

Каждый элемент, входящий в сущность, характеризуется одним и тем же набором атрибутов.

Это означает, что:

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

Требования 1NF обязательны для выполнения.

Обычно атрибуты просто характеризуют элемент (например, человека зовут Иван). Но некоторые позволяют уникально его идентифицировать (например, этот человек имеет паспорт с номером 4505 123456). Такие идентифицирующие атрибуты называют ключевыми атрибутами (или первичными ключами, или просто ключами).

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

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

Например, у человека может быть ещё и кредитная карточка, номер которой уникален. Однако идентифицируют человека, как правило, всё же по паспорту, а не по кредитной карточке (всё зависит от предметной области: иногда номер карточки может оказаться важнее – и тогда именно он используется в качестве первичного ключа).

При проектировании для Битрикса следует учитывать, что первичным ключом для этой системы всегда является ID элемента. У большинства объектов в Битриксе есть также поле CODE, которое может использоваться в качестве вторичного ключа, если контролировать его обязательность и уникальность (по умолчанию это поле необязательно и неуникально).

Поясним на примере. Требуется сделать прайс-лист на джинсы. Пусть цена джинсов зависит от названия модели и от размера. Тогда ключом будет пара полей «наименование-размер», а неключевым атрибутом – «цена». Такая таблица удовлетворяет требованиям 2NF.

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

Мы по-прежнему можем использовать пару «наименование-размер» в качестве первичного ключа, однако для поиска цены поле «размер» становится лишним, что не соответствует 2NF (цена зависит от составного ключа «наименование-размер» точно так же, как и от части ключа – поля «наименование»). Поэтому следует сделать наименование первичным ключом, а поле «размер» исключить из прайс-листа (а если всё-таки надо сохранить данные о том, каких размеров бывает каждая из моделей джинсов, следует организовать отдельную таблицу).

Для инфоблоков Битрикса требование 2NF выполняется всегда, поскольку в качестве первичного ключа всегда выступает только один атрибут – ID.

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

Имя атрибута в классическом варианте – это существительное в единственном числе (Наименование, Дата, Иллюстрация) либо – только для булевских полей! – утверждение со словом «эта/это/этот» (ЭтоПроплаченнаяНовость).

Атрибуты могут быть обязательными либо опциональными (optional). Так, например, у каждой новости должно быть название (обычно вместо Название применяют слово Наименование), но не всегда есть иллюстрация. Опциональные поля на IDEF1x-диаграмме отмечаются знаком (O).

Visio выводит очень подробную информацию о типе атрибута. Однако в большинстве случаев при проектировании для Битрикса вам не придётся проставлять максимальную длину поля или выбирать конкретный тип. Достаточно ограничиться более общими типами.

Атрибуты бывают следующих типов, предполагающих совершенно разные подходы к обработке и использованию хранящихся в них данных:

• скалярные – по таким полям легко осуществлять поиск и фильтрацию: например, находить книги по названию или по году выпуска:
  • число – N-Signed Integer;
  • дата – T-Date&Time;
  • строка текста – S-Fixed Length;
  • булевский тип (да/нет) – L-True or False;
• большой текст (S-Large Length) – по таким полям, за редким исключениям, не строят отборы, а если и строят, то на основе сложного полнотекстового поиска: например, найти все книги в стопке, в текстах которых встречается слово «вечность» – непростая задача не только для человека, но и для сервера (для повышения быстродействия применяются специальные меры);
• бинарные картинки и другие файлы (R-Fixed Length, R-Variable Length или R-Picture) – с такими данными, как правило, не производится никаких других действий, кроме хранения и отображения;
• ссылочный тип (разумеется, не следует путать этот тип со строковым типом, где хранится какой-либо URL).

Для ввода данных о типах в Visio проще всего пользоваться Portable data type (ODBC), а результат смотреть уже на самой диаграмме.

В Битриксе нет выделенного булевского типа – вместо него используется либо тип Список, либо тип Строка с ограничением на ввод только Y или N.

Внешний ключ. Классификация

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

Следующее определение связи – частное (относится к кратности «один-ко-многим»).

С понятием связи часто упоминают понятие классификатора (просьба не путать с кодовыми классификаторами вроде штрих-кодового EAN13 или книжного ISBN).

Если вариантов классификации одной и той же сущности несколько (как в приведённом примере для книг: по издательствам и по авторам), то такую классификацию называют многоаспектной.

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

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

Несмотря на то, что такая форма весьма удобна для восприятия человеком, она избыточна. Так, отношение «Мармит – Москва, ул. Маркса Спенсера, 23» повторяется более одного раза. Если мы знаем адрес издательства «Мармит», то достаточно указать, что книги «Основы мармитологии» и «Мармитология и жизнь» выпущены издательством «Мармит», а его адрес можно посмотреть в адресном справочнике вида «издательство-адрес».

Первоначальный вариант не соответствует 3NF, поскольку адрес издательства относится к издательству, но не относится напрямую к книге. Собственно, и название издательства не относится к книге: оно относится тоже к издательству. К книге относится лишь факт принадлежности к издательству.

Выполним преобразования, разбив таблицу на две.

Книги

Издательства

Теперь в таблице «Книги» хранится только информация непосредственно о книгах, а в таблице «Издательства» – только информация непосредственно об издательствах. Не наблюдается также избыточности данных (каждое значение полей, не являющихся ID, встречается ровно один раз). Таким образом, мы добились соответствия 3NF.

Кратность связи «один-ко-многим». Опциональность связи

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

Пусть имеется связь между сущностями А и Б.

Так, каждая книга издаётся только одним издательством. При этом каждое издательство может издавать одновременно несколько книг.

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

• Издательства издают (кого? что? – винительный падеж) Книги. Книги издаются (кем? чем? – творительный падеж) Издательствами.
• Авторы пишут Книги. Книги пишутся авторами.
• Новости относятся к Темам. Темы включают в себя Новости.

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

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

Обратите внимание, что внешний ключ классифицируемой сущности всегда должен иметь тот же тип данных, что и первичный ключ классификатора. В случае Битрикса это всегда целое число (N-Signed Integer).

В нотации IDEF1x связь обозначается штриховой линией. Со стороны «многие» рисуется чёрный кружок.

Для создания связи в Visio необходимо перетащить на рабочее поле фигуру Relationship и подтащить её концы по очереди к соответствующим сущностям (у них должна появляться красная рамка). После этого надо кликнуть на связь, перейти на вкладку Definition, выделить ключевое поле у классификатора (Parent) и поле внешнего ключа у классифицируемой сущности (Child), нажать кнопку Associate. После этого на форме появится линия связи, а напротив внешнего ключа в классифицируемой сущности появляется маркер (FK) (Foreign key).

Необязательные связи в IDEF1x помечаются ромбиком со стороны классифицируемой сущности. Visio делает это автоматически.

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

Атрибуты типа Список

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

На инфологической модели установлена связь кратности «один-ко-многим» между полем Важности сущности Новости и полем ID сущности СтепениВажности:

• Новости имеют СтепениВажности;
• каждая Новость обязательно имеет одну и только одну СтепеньВажности;
• может быть несколько Новостей одной и той же СтепениВажности.

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

Однако предположим, что при дальнейшем общении с заказчиком выяснилось, что степеней важности всего три, и от степени важности новости существенно зависит способ её отображения на сайте:

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

Итак, в обозримом будущем не предполагается пополнение классификатора СтепениВажности. А если он всё-таки будет пополнен, то придётся переписывать код сайта, чтобы поддержать новые варианты важностей (например, через год работы сайта заказчик захотел, чтобы супер-важные новости отправлялись зарегистрированным пользователям в виде SMS). Более того, сущность СтепениВажности не содержит других полей, кроме ID и Наименование.

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

Использование атрибута типа Список вместо отдельного инфоблока позволяет:

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

Для обозначения в Visio атрибута типа Список (то есть атрибута, варианты значения которого ограничены заранее известным списком) следует выбрать атрибут, нажать кнопку Edit, выбрать вкладку Check, после чего в поле Value последовательно вводить варианты значений и нажимать кнопку Add.

Кратность связи «один-к-одному». Дискриминация

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

Для Битрикс-проектирования появление связей кратности «один-к-одному» характерно, в основном, при использовании приёма дискриминации.

Смысл приёма в следующем. Пусть Интернет-магазин торгует только двумя видами товаров: книгами и музыкальными CD.

Мы видим, что у них есть общие атрибуты: ID, Наименование, Издатель, Цена. Однако только у книг есть атрибут ТипПереплёта и КоличествоСтраниц. И только у дисков есть Длительность. То есть, обе сущности:

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

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

Однако обратите внимание на поле ТипПереплёта. У книг на предыдущем рисунке оно было обязательным. Но поскольку к дискам эта характеристика неприменима, пришлось сделать это поле опциональным. Это означает, что теперь придётся при вводе и обработке также контролировать это поле программно.

Второй, более распространённый, вариант – создавать сущность-родитель (она объединяет в себе все общие атрибуты исходных сущностей) и сущности-потомки (каждая из них содержит только те атрибуты, которыми она отличается от остальных). При этом атрибут ТипТовара называют дискриминирующим атрибутом или дискриминатором: именно он определяет, в какой сущности-потомке содержатся данные, расширяющие данные сущности-родителя.

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

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

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

Если в Visio вы правильно соедините родителя с дискриминатором специальной связью Parent to category, а дискриминатор с каждой из сущностей-потомков специальной связью Category to child, то все обозначения будут расставлены автоматически. Вам останется только, щёлкнув по дискриминатору, в панели свойств выбрать дискриминирующий атрибут и отметить флаг Category is complete (он означает, что мы перечислили все возможные подвиды родительской сущности – а так всегда и надо делать).

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

Итак, пусть изначально было N сущностей, обладающих общими свойствами.

Отображение дискриминации в одну таблицу (инфоблок)

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

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

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

Отображение дискриминации в N таблиц

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

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

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

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

В Битриксе для свойства типа «Привязка к элементу» можно легко указать, к элементу какого именно инфоблока должны делаться привязки. Или можно указать, что привязка может быть к элементу любого инфоблока. А вот ограничить список инфоблоков, к элементам которых может осуществляться привязка, увы, невозможно в режиме настройки инфоблока (для этого придётся воспользоваться обработчиками событий).

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

Отображение дискриминации в N+1 таблицу

Создаётся родительская таблица (инфоблок), которая содержит общие атрибуты и ссылку на строку дополнительной таблицы, а также N таблиц, содержащих только уникальные атрибуты каждой из сущностей. Дискриминатором является выделенный атрибут.

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

Пользоваться «общей» частью удобно точно так же, как в первом варианте. А вот при использовании частных свойств всё не столь однозначно.

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

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

Конечно, можно сначала загнать в массив список ID’ов выбранных элементов, а потом сделать один запрос к дополнительному инфоблоку, выдав этот массив в качестве $arFilter (именно так обычно и следует поступать). Но это дополнительное кодирование.

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

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

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

Отображение дискриминации в 5 таблиц

Создаются:

• таблица с общими атрибутами,
• таблица со списком возможных значений дискриминатора «ID значения дискриминатора – наименование значения дискриминатора»,
• таблица видов свойств «ID вида свойства – наименование вида свойства»,
• таблица назначений свойств «ID вида свойства – ID значения дискриминатора» (в ней указывается, у какой сущности какие имеются свойства),
• и таблица значений свойств «ID элемента основной таблицы – ID вида свойства – значение свойства».

Этот вариант следует применять, если всё-таки оказалось, что список возможных значений дискриминатора не является конечным или конечен, но очень велик.

Этот способ весьма тяжёл для классических таблиц, поскольку SQL-запрос получается достаточно сложным (либо разбивается на несколько запросов).

В Битриксе, если реализовывать его «в лоб» на уровне API инфоблоков, этот способ крайне неэффективен (и в плане удобства редактирования, и в плане производительности), и пользоваться им стоит только в самом крайнем случае. Поэтому описание этого способа мы приводим лишь для ознакомления.

Кратность связи «многие-ко-многим». Развязка

Довольно распространён третий, последний, вариант кратности связи – связь «многие-ко-многим».

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

каждая книга может быть написана несколькими авторами;

каждый автор может написать несколько книг.

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

При переходе от инфологической модели к даталогической от связей «многие-ко-многим» непременно избавляются: для этого есть несколько способов.

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

Если, например, выяснится, что автор Иванов родился, не в 1937-м, а в 1940-м, то нужно будет внести изменения сразу в несколько строк. Если вдруг из ассортимента магазина будет исключена книга «Основы мармитологии», то придётся удалить более одной строки. При этом информация об авторе Петрове также будет утрачена, так как он не написал других книг – а ведь снятие с продажи книги не всегда означает, что с сайта должна пропасть информация об её авторе.

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

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

Так, если сущности А и Б связаны с кратностью «многие-ко-многим», то создаётся «развязочная» сущность с именем А_Б, содержащая внешние ключи сущностей А и Б. При этом совокупность этих внешних ключей является первичным ключом сущности А_Б.

Все три сущности могут быть напрямую отображены в три таблицы БД.

На следующем рисунке видно, что у сущности Авторы_Книги первичный ключ составной – и оба его компонента являются внешними ключами (FK) исходных сущностей Авторы и Книги. Связи между сущностями теперь имеют кратность «один-к-одному». И если понадобится изменить год рождения автора, то будет изменена лишь одна строка сущности Авторы. При снятии с продажи одной книги будет удалена лишь одна строка из сущности Книги, никоим образом не затронув сущность Авторы (об удалении строк из Авторы_Книги чуть позже).

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

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

Согласитесь, достаточно громоздко? Однако в модели всё выглядит значительно красивее: достаточно добавить два неключевых поля Гонорар и ВкладВРаботу в сущность Авторы_Книги.

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

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

Множественное ссылочное свойство заменяет собой «развязочную» таблицу: по сути, оно и есть логическая таблица, у которой первый столбец – всегда ID текущего элемента, а второй стобец – ID’ы элементов, на которые он ссылается.

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

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

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

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

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

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

В Visio для изображения множественного свойства используется условное обозначение [LIST].

Для того чтобы поставить отметку [LIST], следует выбрать на панели свойств нужное свойство, нажать кнопку Edit, выбрать вкладку Collection и отметить Ordered group of values (List) – напоминаем, именно этому варианту списка значений соответствует множественное поле Битрикса.

Читатели, знакомые с системой «1С:Предприятие», наверняка заметят аналогию с табличными частями документов (версии 7.7 и 8) и справочников (только 8). По сути дела, множественные свойства Битрикса – это табличные части 1С, но имеющие только один столбец.

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

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

Например, можно создать в инфоблоке Книги два дополнительных множественных свойства: Гонорары и ВкладыВРаботу. Тогда первый элемент в списке авторов будет соответствовать первому гонорару и первому вкладу, второй автор – второму гонорару и второму вкладу и т.д.

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

Каскадное удаление и проверка целостности данных

Каскадное удаление можно включить либо на уровне СУБД (например, в Microsoft SQL Server для этого достаточно установить соответствующий флажок на форме редактирования связи), либо отработать на уровне триггеров.

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

В настоящее время Битрикс практически не поддерживает ни каскадное удаление, ни проверку целостности данных. Так, при удалении элемента классификатора – свойство-ссылка элемента классифицируемой сущности просто-напросто очищается.

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

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

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

В отличие от бутылочного лимонада, здесь не будет пузырьков (фанаты, однако, могут использовать сифон). Вкус чем-то напоминает Schweppes Bitter Lemon, но более мягкий и ароматный.

Ингредиенты домашнего лимонада:

• два средних лимона с неповреждённой кожурой;
• апельсиновый ликёр Triple Sec или Cointreau (опционально, 4-6 столовых ложек);
• сахар (полстакана);
• фильтрованная вода без хлорки (1,5 л);
• ванилин (на кончике ножа);
• шафран/куркума (щепотка);
• листочки свежей мяты (по желанию).

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

Поставьте эмалированную кастрюлю с водой на огонь.

Теперь разрезаем лимоны поперёк долек пополам, затем каждую половинку разрезаем ещё раз пополам, но уже вдоль долек. Проще всего выдавливать сок из лимонов, разрезанных именно таким образом – сдавливая «уголки» четвертушек.

Как только вода закипит, следует выключить огонь. Говорят, витамин C не разрушается при кипении воды, однако, наверное, всё-таки лучше лимонад не варить.

Сок и цедру нужно вылить в воду, туда же положить ванилина и немножко куркумы (она придаст приятный жёлтый оттенок напитку).

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

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

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

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

— Не ходите, дети, в Африку гулять!

Строго говоря, Синайский полуостров, на котором расположен египетский город-курорт Шарм-Эль-Шейх – это не совсем Африка. Но и не Азия – а так, не пойми что. Похоже, скорее, на район Большой Ялты в не пойми чьём Крыму.

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

История и природа Шарм-Эль-Шейха

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

Естественная же природа Синая – это высокие горы из песчаника, возвышающиеся посреди каменистой пустыни.

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

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

Кстати! Если вы хотите узнать, как реально будет выглядеть ваш отель (на сайте отеля и в рекламных проспектах всё соооовсем по-другому), то установите Google Earth, введите название отеля – и смотрите. Конечно, актуальность фотографий со спутника составляет порядка двух лет, но пользовательские фотографии, которые привязываются к этому месту (в виде синих квадратиков сервиса Panoramio) могут быть вполне свежими. Вы не поверите: маркетоиды отелей, похоже, до сих пор не знают об этом сервие – а потому в Google Earth вы почти не встретите рекламных фотографий, снятых исключительно с удачных ракурсов.

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

Подумать только: какое торжество технологий! Ещё совсем недавно качественными фотографиями со спутника могли пользоваться только вояки, а сейчас мы можем получить массу информации и смотреть реальные пейзажи, привязанные к местности. Дух захватывает!

Как добраться до Шарм-Эль-Шейха

Аэропорт оказался вполне европейским: «рэйс васэмнадцат пасадка бистро-бистро». Это не тот приятный голос девушки-диспетчера в Домодедово, но зато вполне дружелюбно и информативно. К слову, девушек в Египте нет. Нигде. За исключением, конечно же, сотрудниц наших турфирм.

Туристический сервис здесь поставлен и отработан великолепно. Единственная заминка была с оформлением египетской «визы». На самом деле, всё просто. Подходите к окошечку, меняете доллары (курс доллара к египетскому фунту по всей стране во всех банках, говорят, одинаковый, поэтому смело можно обменивать в аэропорту). Оплачиваете в это же окошечко стоимость визы и заполняете прилагающуюся карточку латинскими буквами.

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

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

Однако мы не сильно заморачивались на этот счёт. Уже через полчаса комфортабельный автобус привёз нас в столь же комфортабельный отель Coral Beach Tiran.

Отели Шарм-Эль-Шейха

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

Впрочем, в октябре, несмотря на 32 градуса на термометре, жара не такая уж и изнуряющая – всё благодаря низкой влажности.

Если рельеф позволяет, то здания отелей строятся террасами – поэтому значительная часть номеров окнами выходит на море. Из окон нашего отеля открывался прекрасный вид на одноимённый остров Тиран.

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

В номере отеля, в отличие от Скандинавии, мы не нашли Библию (кто бы сомневался). Зато, выдвинув ящик стола в номере, всегда можно узнать, где восток.

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

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

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

Вообще на фоне арабов наши смотрятся как-то… Да так же, как на фоне европейцев и прочих народов.

Египетский алкоголь несъедобен в принципе: видимо, из-за исламского «сухого закона» работники алкогольной промышленности толком не могут продегустировать и ужаснуться. Но наших это не останавливает: халява ведь!

Умеренность в еде тоже не принадлежит к нашим национальным чертам – и для этого здесь созданы все условия. Для тех, кто проспал завтрак или даже обед, организована «система перекусов». Многие говорят, что еда по системе al-inclusive не сильно разнообразная. Ну, может, оно и так – но для тех, кто в рабочие дни питается бутербродами или, в лучшем случае, в столовке, разнообразия будет вполне достаточно. А уж выпечка поразит воображение кого угодно.

У египтян, помимо алкоголя, проблемы ещё и со свининой. Поэтому они нарушают сразу две заповеди шашлычника: они делают шашлык из говядины – и не на углях, а на открытом огне. Вот так:

Пожалуй, главная достопримечательность любого шармэльшейхского отеля – это коралловый риф. Там РЫБКИ! Описывать их бесполезно, а показывать фотки, сделанные без оборудования для подводной съёмки, стыдно. Масштаб этого зрелища напоминает «Подводную одиссею команды Кусто» – или, на худой конец, хельсинкский аквариум (и в тысячу раз масштабнее севастопольского аквариума – хотя у нас там теперь тоже есть свой крошечный коралловый риф).

Причём рыбки не где-то вдалеке, а плавают прямо вокруг вас. И трутся об ноги, как коты.

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

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

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

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

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

Жители Египта

В Египте нам пришлось пообщаться со многими арабами, что послужило значительному пересмотру взглядов на арабский мир. Так, на базарах – всё те же люди, знакомые нам по московским рынкам, хватающие за руку и ведущие себя панибратски. Но если вы заболеете (а такое с отдыхающими, увы, случается нередко: непривычная еда и вода, резко отличающийся от нашего климат, отравления брюквой в некоторых отелях…), то к вам в течение 15 минут прибудет самый настоящий интеллигентный доктор в очках, а не шаман с бубном.

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

Дорожное движение в Египте

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

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

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

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

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

Сувениры из Египта

Главный египетский сувенир – это папирус, наряду с настоящим египетским каркадэ (то, что продаётся у нас, не идёт ни в какое сравнение) и восточными специями. Кусочки мумии и обломки пирамиды, купленные с рук, не в счёт.

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

Золотистый и коричневый папирусы отличаются только временем выдержки под прессом: 6 или 12 дней соответственно. Папирус при этом должен быть многослойным – и на просвет волокна папируса должны лежать крест накрест (иначе это не папирус, а лист банана). На genuine-папирусы ещё ставят штампы, но мы бы этому не доверяли.

Сейчас на папирусах рисуют не только фараонов и богов – могут нарисовать даже вас. Но если вам не нравится китч, выбирайте папирус с аутентичным рисунком без всяких нелепых подписей на английском. Так, «Глаз Хороса» шикарно будет смотреться в офисе вместо портрета строгого Путина (который как бе говорит: «Я всё вижу, вы не работаете!»). А если вы купите «Дерево жизни» на чёрном фоне и догадаетесь повесить его не в блевотно-золотистую рамочку (они почему-то у египтян пользуются особой популярностью), а в хорошую чёрную раму из IKEA (да-да, собирается за час) с креповым чёрным паспарту, то вы получите шикарное украшение для дома за копейки.

Если повезёт, папирус вы сможете купить прямо в отеле (нам очень повезло). Правило «на рынке дешевле» тут не работает: видимо, в отеле дорожат репутацией магазинчиков. А вот за всем остальным лучше съездить на восточный базар – в так называемый «Старый Город» – или хотя бы просто на местную «ялтинскую набережную» – Наама-Бэй.

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

У нас отлично выжили зелёный и розовый перцы (фантастический аромат!), коричные дубины (палочками их язык не поворачивается назвать). И, конечно, каркадэ. Берите дорогой, большими цветками, с сильным ароматом. А потом всю зиму: граммов сто сахара на литр воды и десяток ложек каркадэ.

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

Мерчандайзеру на заметку: любой товар на меховой полке выглядит шикарно, особенно если это «египетская виагра», которую вам обязательно предложат. Будете за Уралом – там будет барсучий жир. У каждого народа снадобье своё.

Экзотических фруктов в Египте не так уж и много. Из реально съедобных – только гигантский египетский манго (его вкус вообще не похож на манго из супермаркета) да сладкий гранат (!) размером с дыню. Зелёные апельсины, финики и прочие хз-фрукты съедобны разве что из любопытства.

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

Торгуйтесь как только можете! Присмотритесь, как это делают более опытные покупатели. Тот же манго местным продаётся по 5 египетских фунтов (около доллара) за килограмм – но вам с вашей европейской внешностью и браслетом отеля его будут пытаться продать за 35–40. Именно поэтому даже в магазинах (за исключением единичных «супермаркетов») нет ценников.

По-русски (как и по-английски) продавцы обычно понимают очень плохо, говорят заученными фразами (хотя объясниться жестами можно всегда). Не ждите вопроса после приветствия: «Можина адын вапрос?» – это риторическая фраза, за которой последует предложение купить хоть что-нибудь. Будьте готовы к тому, что местный маркетинг весьма агрессивен: вас будут хватать за руки, тыкать товарами прямо в вас – и совершенно искренне каждый раз обижаться, если вы будете проходить мимо.

В Египте есть своё местное мегаживотное – «ферблюд». На нём ездят, пьют верблюжье молоко, с его помощью ищут родники, из шерсти делают одеяла и коврики, мясо идёт на шашлыки (очень вкусно!), из кожи делают что-то вроде пуфиков, а также верблюдами расплачиваются с родственниками невест. На маленьком верблюжьем коврике зимой очень приятно постоять ногами – да и рисунок гениален в своей ёмкости: палатка бедуина, «ферблюд», пальма, пустыня и горы – вот и весь Синай.

Если надумаете покупать «стульчик», то берите бесцветный: красители используют не ахти какие. Потом хорошенько вымойте и просушите на египетской жаре (только не на прямом солнце) – иначе будет… гмм… попахивать верблюдом. Зато потом в стульчик в качестве начинки поместится вся одежда, которую носить уже нельзя, а выбросить всё ещё жалко.

И обязательно – «роза пустыни». Видимо, как раз о ней песня Стинга Desert Rose.

Синайская пустыня «для чайников»

Собственно, есть два способа увидеть пустыню: «для всех» и «для фанатов».

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

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

Рекомендуется заранее закупить «арафатку» – клетчатый платок, который арабы повязывают на голову (семантическую близость с Ясиром Арафатом подтвердить не удалось). Арафатка отлично защитит вас от пыли при движении по пустыне, а ещё в ней нежарко (защищает от солнца и при этом голова не потеет). Не бойтесь, завязывать арафатку вас с удовольствием научат аборигены.

Пять минут инструктажа жестами – и вы заправский водитель квадроцикла. Более подробного инструктажа не требуется: несмотря на то, что на борту написано гордое Honda, девайс убит настолько, что глохнет каждые сто метров, а ехать быстрее 30 км/ч не может в принципе. Но при движении по «волночкам» на песке вы всё прочувствуете даже на такой скорости. А главное – вы таки увидите в первом приближении Синайскую пустыню.

Потом вас покатают на верблюде. Животные, как оказалось, весьма пахучие. Иногда они почему-то начинают бурчать, как двигатель внутреннего сгорания. Страшнее всего, когда верблюд «паркуется»: он резко ложится на передние лапы, и вас бросает вперёд, а потом назад – держитесь крепче! Поскольку поездить на верблюде в средней полосе России приходится нечасто, то с непривычки через пять минут катания натираешь себе всё что только можно: у седла отсутствуют стремена. С уважением смотришь на арабов, которые могут на этом животном пересечь пустыню за месяц.

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

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

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

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

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

Настоящие бедуины, кажется, жевут вне человеческой цивилизации. У них нет паспортов, а также таких понятий, как образование и здравоохранение. Из современных благ они пользуются разве что радиоприёмниками. Конечно, они не могут не замечать окружающую их цивилизацию, но познания о современном мире у них весьма специфические. К примеру, самолёт – это для них «железная птица». Таким образом, образование заменяется жизненным опытом. Образованный пилот самолёта умрёт в пустыне к концу недели, а бедуины живут в ней всю жизнь.

Настоящая Синайская пустыня и Цветной каньон

Первый способ позволяет увидеть пустыню, но по-настоящему почувствовать её, увидеть не-бутафорских бедуинов и верблюдов позволяет только второй способ – «Цветной каньон + монастырь Святой Екатерины».

Внимание! Не стоит ехать на эту экскурсию с девушкой или пожилым родственником, а также если вас укачивает даже в маршрутке. За 14 часов вы накатаете с водителем-египтянином (см. главу о египетском дорожном движении) порядка 600 км, из которых километров 50 – по оффроаду. Но оно стоит того!

Для тех, кто не умеет с первого взгляда на карту определять местность – слева направо: Африка, Суэцкий залив Красного моря, Синайский полуостров, Акабский залив Красного моря, Саудовская Аравия.

В качестве транспорта используется внедорожник Toyota Land Cruiser, но не простой, а «Ближний Восток Edition». Несмотря на спецподготовку, машина убивается за пару лет эксплуатации. Абразивные свойства песка испытала на себе американская и немецкая техника ещё во время Великой Отечественной. На современных машинах (и даже на автобусах) воздухозаборники подняты вверх и оснащены фильтрами.

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

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

Арабские цифры – это закорючки, как на этом автомобильном номере. Причина путаницы в том, что наши цифры – арабские не в смысле начертания, а в смысле принципа записи. Десятичный принцип записи (в отличие от римских цифр) как раз и изобретён арабами.

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

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

По пути можно полюбоваться видом на Саудовскую Аравию (она по другую сторону залива).

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

Неподалёку от оазиса джип сворачивает с асфальтовой дороги: дальше путь пролегает по руслу высохшей древней реки. «Волночки» на песке смотрятся очень красиво, но когда по ним едешь с приличной скоростью, взметая в воздух тучи песка, это больше всего напоминает езду по стиральной доске. Мясо в прямом смысле отрывается от костей, а голова стучится о потолок (какие такие ремни безопасности?). В общем, более экстремальной поездки в нашей жизни ещё не было.

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

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

На въезде в каньон в машину обязательно подсаживается настоящий бедуин. Они контролируют эту территорию и следят за тем, чтобы «провал не проваливался». С ними договаривается водитель. Говорят, что также бедуины обеспечивают безопасность туристов – интересно, как? Этакий аналог лесника.

Стенки каньона образованы цветными песчаниками – наверное, именно из-за них он и получил своё название.

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

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

Именно в Цветном каньоне мы увидели дикорастущую верблюжью колючку. Она оказалась весьма симпатичным растением с плотными пухлыми листьями (как у комнатного «денежного деревца») – и она почему-то цвела.

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

Именно в такой пустыне разбился лётчик в «Маленьком Принце» Экзюпери. Пески, зной и безнадёжность, а потом – дорога к роднику под звёздами.

Потом подъём по крутой тропе – и вы снова на верхнем краю каньона. Фотографы-энтузиасты могут захватить монопод и собрать панораму.

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

Пока джип едет по бесконечной дороге с однообразными пустынными пейзажами, араб-экскурсовод на ломаном русском пересказывает сюжет мультфильма «Суперкнига». Было даже как-то стыдно, что мусульманин знает все эти библейские сюжеты лучше, чем мы, правоверные христиане.

Если в двух словах, то именно в этом месте Моисею впервые явился Бог в пламени горящего тернового куста, известного как «неопалимая купина». Этот куст существует и поныне (и предприимчивые арабы продают по 5 долларов заламинированные листочки). Говорят, надо подержаться за веточку на счастье.

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

Монастырь уникален ещё и тем, что за одними стенами есть и христианский, и мусульманский храмы. Так, когда в Египет пришли мусульмане, они методично разрушали христианские монастыри. Здешние же монахи не растерялись и быстро построили мечеть, причём её минарет был выше (а значит, главнее) колокольни. Когда ревнители ислама пришли в монастырь, то не стали его разрушать: мечеть уже действовала.

Потом, когда опасность миновала, колокольню надстроили.

Сейчас храмы монастыря действуют. Примечательно, что в православный храм пускают только славян (служители интересуются на входе вероисповеданием).

Каждому пришедшему в храм священник вручает на память серебряное колечко.

Экскурсия в заповедник «Рас-Мохаммед»

Обязательно стоит съездить в заповедник «Рас-Мохаммед». Нет, он совсем не похож на Беловежскую пущу: здесь снова пустыня. Это самый кончик Синая: песчаные дюны и холмы. Вышки сотовой связи питаются от огромных солнечных батарей.

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

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

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

«Магический залив», расположенный неподалёку, – это мелководная лагуна с очень тёплой водой и песочком на дне. Здесь приятно искупаться. Экскурсовод утверждает, что своё название он получил из-за того, что не виден со спутника. Мы проверили в Google Earth – таки виден. Поэтому лучше поверить в легенду о том, что у искупавшегося в нём с головой человека исполнится любое желание.

В отличие от туристов, местные женщины, увы, могут только помочить в нём ноги.

На выезде из заповедника стоит рукотворный Стоунхендж. Говорят, эти камни образуют слово «Аллах» на арабском.

В заключение

Терминал вылета в шармэльшейхском аэропорту напоминает шатёр (к сожалению, фотографировать здесь не разрешают).

А дальше – обратный путь домой. Красная пустыня сменяется Средиземным морем, потом цветущей зелёной Турцией, а там уже и наш Крым. Если повезёт, самолёт пролетит прямо над Севастополем (мы же пролетали его по дороге «туда»; жаль, SMS нельзя отправить).

Когда GPS-приёмник показал, что мы пролетаем над Харьковом, увидели интересную картину: плотный облачный слой был разорван точно по контуру города. Неужто и правда город настолько влияет на экологию в планетарном масштабе?

Да, кстати, мы как-то совсем забыли упомянуть. В Египте по-настоящему классно отдыхать. Загорать на пляже, купаться в необычно тёплом море, валяться в шезлонге и отсыпаться на мягкой кровати в номере. Но не всё же время!

Из-за дебильной книжки «Наши в Турции» Экслера и подобных ей идиотских рассказов о Егитпе обычно складывается впечатление, что Египет – это сплошной отель с сидящими за барной стойкой пьяными русскими. Для кого-то, может, это и так – главное, с каким настроем и для чего туда ехать. Вы не поверите: мы намеренно не поехали смотреть визитную карточку Египта – пирамиды – просто потому, что даже в окрестностях Шарм-Эль-Шейха нашли массу всего интересного. А в Каир с Луксором слетаем как-нибудь отдельно, в другой раз.

До свидания, Египет!

Здравствуй, Россия!

Сразу предупреждаем: не надо брать 200-граммовый стакан (на снимке – макросъёмка стопки на 60 мл). Хотя…

Этот коктейль вам лучше всего сделает бармен ресторана «T.G.I. Friday’s» на «Новослободской». Нам пришлось отступить от рецептуры и изрядно потренироваться, прежде чем получилось что-то похожее.

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

Во «Фрайдисе» используются:

• ликёр Triple Sec (трайпл сек) – сухой апельсиновый ликёр, можно заменить ликёром Cointreau (куантро);
• гранатовый ликёр Grenadine (гренадин), можно заменить брусничным сиропом Lingonsaft из IKEA;
• персиковый ликёр, водка и Baileys (бейлис).

Ингредиенты для домашних условий:

• ликёр Triple Sec или Cointreau (15 мл);
• красный сироп Lingonsaft (20 мл);
• качественная водка, лучше Finlandia (15 мл);
• сливочный ликёр Baileys (5-10 мл).

Смиритесь с тем, что с первого раза у вас ни черта не получится.

Начинается всё безобидно: наливаем в 60-миллилитровую стопку апельсиновый ликёр Triple Sec (или Cointreau). Потом по капле вливаем красный сироп – и он послушно опускается на дно. Если у вас в итоге не получится чётко видимой границы между ликёром и сиропом – то выпейте смесь сразу и начните заново.

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

А вот теперь высший пилотаж. Налейте ликёр Baileys в крышечку от бутылки. Возьмите коктейльную трубочку, наберите в неё бейлис (чур, не пить!), зажмите верхний конец пальцем. Убедитесь, что из трубочки не капает.

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

Если не удалось изготовить коктейль 4 раза кряду, то сделайте себе что-нибудь попроще, а к коктейлю «Опухоль мозга» вернитесь как-нибудь в другой раз.

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

Надеемся, вы не выпили весь Blue Curacao, когда делали «Электрик лемонейд». Вам ещё понадобятся яичный ликёр «Адвокат» (Advocaat), водка, красный сироп (например, тот, что продаётся в IKEA – брусничный Lingonsaft) и – как это ни странно – молоко. 

Ингредиенты (на пару коктейлей):

• ликёр Blue Curacao (30 мл + 20 мл);
• качественная водка, лучше Finlandia (10 мл);
• ликёр Advocaat (30 мл);
• молоко (10 мл);
• красный сироп (20 мл).

Коктейли изготовить непросто, поэтому лучше с них начинать, а не заканчивать.

Сначала сделаем коктейль «Украинский флаг». Налейте в 60-миллилитровую стопку до половины яичный ликёр Advocaat.

К сожалению, украинский флаг, на самом деле, не жовто-блакiтний, а блакiтно-жовтий. Поэтому придётся снизить плотность Blue Curacao, чтобы он оказался сверху. Для этого в отдельной посуде (удобнее всего использовать стаканчик с «носиком» из химического набора) смешаёте водку и Blue Curacao в пропорции 1:1. Полученную смесь медленно, по ложечке долейте в стопку с «Адвокатом».

Теперь приступим к коктейлю «Российский флаг». Нижним слоем триколора будет брусничный сироп Lingonsaft (наверное, можно попробовать и гренадин). Далее по ложечке медленно наливаем неразбавленный Blue Curacao (Внимание! Именно неразбавленный, то есть не так, как для украинского коктейля).

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

Этот рецепт хорош тем, что вам наверняка не придётся придумывать тост:

— Ну, за дружбу братских народов!

Американцы со своими звёздами и полосами на флаге отдыхают.

С появлением IIS7 в составе Windows Server 2008 у владельцев сайтов на «Битриксе» появилась альтернатива. Если раньше установка Битрикса на Windows была сопряжена с огромными трудностями (особенно в плане производительности), то под IIS7 «Битрикс» заработал в полную силу. FastCGI, очереди запросов, а также отсутствие необходимости в применении nginx позволяет сконфигурировать web-сервер практически без «танцев с бубном».

В этой статье содержится пошаговая инструкция по установке и базовой настройке всех элементов web-сервера, необходимых для запуска сайта на «1С-Битрикс: Управление сайтом».

Установка IIS7

Запустите Server Manager, откройте в дереве оснастки Roles, нажмите Add Roles, выберите Web Server (IIS).

Если вы планируете использовать стандартный SMTP- или FTP-сервер от Microsoft, то необходимо в списке Role Services отметить IIS6 Management Compatibility (управление этими серверами производится только из старой оснастки on IIS6).

IIS7 можно администрировать удалённо, подключаясь к нему не с помощью RDP, а с помощью оснастки. Для этого надо отметить Management Service.

Если вы планируете использование FTP-сервера от Microsoft, то отметьте FTP Publishing Service.

Для работы с PHP в режиме FastCGI (основное достоинство IIS7 для «Битрикса») необходимо отметить пункт Application Development - CGI.

Скорее всего, вам также пригодятся Logging Tools.

Все эти дополнительные функции вы сможете добавить и позже, выбрав в дереве оснастки Roles - Web Server (IIS) и нажав Add Role Services.

Дальнейшая работа может производиться с помощью оснастки IIS7, которая разительно отличается по внешнему виду и количеству настроек от оснастки IIS6.

Установите апдейт для IIS, дабы избежать возможных проблем с Redirection.

Настройка PHP

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

Скачайте дистрибутив PHP5 (Microsoft рекомендует non-thread-safe, однако eAccelerator с ним не очень-то работает).

Установите (например, в папку C:\Websrv\PHP) из MSI, включив следующие Extensions (их также можно будет прописать позже вручную в виде extension=имяфайларасширения.dll):

• MySql
• GD2
• LDAP (если будете изпользовать LDAP-авторизацию)
• OpenSSL
• SMTP
• Win32ps
• Win32scheduler
• zip

Откройте файл php.ini в Блокноте и установите (или раскомментируйте) следующие параметры:

1. fastcgi.impersonate = 1
2. cgi.fix_pathinfo = 1
3. cgi.force_redirect = 0
4. open_basedir = C:\Inetpub (или другая папка, в которой будут ваши сайты)
5. short_open_tag = On (в Битриксе используется <? вместо <?php)
6. extension_dir = “C:\Websrv\PHP\ext”
7. upload_tmp_dir=”C:\inetpub\temp”
8. session.save_path=”C:\inetpub\temp”
9. allow_call_time_pass_reference = On
10. display_errors = On

Вы можете в CMD запустить команду:

C:\Websrv\PHP\php -info

Если вы сделали всё правильно, то будет выдан этот же файл конфигурации.

Теперь нужно настроить IIS таким образом, чтобы php-файлы обрабатывались модулем FastCGI. На Home-странице в оснастке IIS выберите Handler Mappings, затем Add Module Mapping.

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

Проверьте корректность привязки. Для этого в папке C:\Inetpub\wwwroot создайте файл test.php, содержащий строку <? phpinfo(); ?>. Откройте в браузере http://localhost/test.php.

Имейте в виду, что по умолчанию в Windows Server 2008 запись в папку Inetpub можно производить только в том случае, если прогрмма, с помощью которой вы собираетесь создать файл, запущен в режиме эскалации. Вы можете либо перенастроить разрешения на эту папку, либо запускать Проводник (или другую программу, с помощью которой вы будете создавать и редактировать файлы) в режиме эскалации (Run as administrator).

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

%windir%\system32\inetsrv\appcmd set config -section:system.webServer/fastCgi /fullPath=’C:\Websrv\PHP\php-cgi.exe’].instanceMaxRequests:10000

%windir%\system32\inetsrv\appcmd set config -section:system.webServer/fastCgi /+fullPath=’c:\Websrv\PHP\php-cgi.exe’].environmentVariables.name=’PHP_FCGI_MAX_REQUESTS’,value=’10000′]

Теперь следует настроить таймауты.

%windir%\system32\inetsrv\appcmd set config -section:system.webServer/fastCgi /[fullPath='C:\Websrv\PHP\php-cgi.exe'].activityTimeout:600

Этой командой мы установим заведомо большое время ожидания IIS’ом окончания выполнения скрипта - 600 секунд.

Теперь в php.ini можно указать, например, следующие значения:

max_execution_time = 240

max_input_time = 240

Установка MySQL

Скачайте MySQL.

В мастере настройки сервера укажите, что это Server Machine.

Выберите Transactional Database Only, чтобы использовать только InnoDB.

Выберите OLTP, чтобы обеспечить выполнение большого количества запросов.

Выберите cp1251, если вы собираетесь работать со старыми проектами на «Битриксе» (в старой кодировке) или Best Support for Multilingualism для новых установок Битрикса.

Поставьте галку Include Bin Directory in Windows PATH, чтобы проще было работать из CMD.

Чтобы нормально работать с cp1251 из консоли, пропишите в my.ini в секции [client] строку

character-sets-dir=”C:/Websrv/MySQL/MySQL Server/share/charsets”

Установка eAccelerator

Скачайте бинарный дистрибутив eAcceleretor.

Переименуйте DLL-файл в eaccelerator.dll и поместите его в папку C:\Websrv\PHP\ext.

В php.ini добавьте строки

[eaccelerator]

extension=eaccelerator.dll

eaccelerator.shm_size=”16″

eaccelerator.cache_dir=”C:\inetpub\temp\eaccelerator”

eaccelerator.enable=”1″

eaccelerator.optimizer=”1″

eaccelerator.check_mtime=”1″

eaccelerator.debug=”0″

eaccelerator.filter=”"

eaccelerator.shm_max=”0″

eaccelerator.shm_ttl=”0″

eaccelerator.shm_prune_period=”0″

eaccelerator.shm_only=”0″

eaccelerator.compress=”1″

eaccelerator.compress_level=”9″

Установка Bitrix

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

При установке вам нужно будет указать C:\Websrv\PHP в качестве папки с php.ini и папку С:\Inetpub - в качестве корневой папки вебсервера.

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

Спозиционируйте сайт на новую папку (например, C:\Inetpub\wwwroot\bitrixtest).

Добавьте для этой папки разрешение Modify для группы IUSR.

Скопируйте в эту папку содержимое сайта.

Удалите из этой папки web.config, входящий в поставку «Битрикса», так как с IIS7 этот файл несовместим. Привязка к PHP уже выполнена средствами консоли IIS, остаётся привязать страницу по умолчанию и страницу 404-й ошибки.

Спозиционируйтесь на сайт bitrixtest в консоли IIS, выберите Default Document, нажмите Add и добавьте index.php.

Создайте пустой файл C:\inetpub\wwwroot\bitrixtest\404.php.

Спозиционируйтесь на сайт bitrixtest в консоли IIS, выберите Error Pages, выберите 404, снимите галку Try to return the error file in the client language (этим будет заниматься не IIS, а непосредственно «Битрикс») и выберите файл C:\inetpub\wwwroot\bitrixtest\404.php.

Всё, можно заходить из браузера по адресу http://independence и запускать Мастер установки «Битрикса» (детали установки).

Обратите внимание! Если в папке вашего сайта на UNIX-системе использовались хардлинки или симлинки, то вам стоит воспользоваться командой

Mklink /D <путь к новому линку> <путь к исходной папке>

Заключение

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