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

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

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

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

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

3.1 О надежности в терминах ISO 9126

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

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

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

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

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

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

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

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

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

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

Физическая совместимость заключается в степени соответствия кодировки информации одинаковым стандартам на машиночитаемые носители.

4. Тенденции в мире систем управления базами данных

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

· Реляционные системы

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

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

· Использование мультипроцессорных организаций

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

Однако с появлением на рынке мультипроцессорных симметричных аппаратных архитектур, производители СУБД были вынуждены пересмотреть организацию своих серверов, допустив в них внутреннюю параллельность. Естественно, это требует очень основательного перепроектирования системы с ее существенным усложнением. Заметим, что в большинстве случаев компании пошли на это после появления в ОС UNIX механизма «легковесных» процессов (threads).

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

· Интеграция

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

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

· Базы сложных объектов, реляционная модель с отказом от первой нормальной формы

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

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

· Активные базы данных

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

Легко видеть, что основа этой идеи содержалась в языке SQL времени System R. На самом деле, что есть определение триггера или условного воздействия как не введение в БД правила, в соответствии с которым СУБД должна производить дополнительные действия? Плохо лишь то, что на самом деле триггеры не были полностью реализованы ни в одной из известных систем, даже и в System R. И это не случайно, потому что реализация такого аппарата в СУБД очень сложна, накладна и не полностью понятна.

· Дедуктивные базы данных

По определению, дедуктивная БД состоит из двух частей: экстенсиональной, содержащей факты, и интенсиональной, содержащей правила для логического вывода новых фактов на основе экстенсиональной части и запроса пользователя.

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

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

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

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

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

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

· Темпоральные базы данных

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

Конечно, можно явно ввести в хранимые отношения явный временной атрибут и поддерживать его значения на уровне приложений. Более того, в большинстве случаев так и поступают. Недаром в стандарте SQL появились специальные типы данных date и time. Но в таком подходе имеются несколько недостатков: СУБД не знает семантики временного поля отношения и не может контролировать корректность его значений; появляется дополнительная избыточность хранения (предыдущее состояние объекта данных хранится и в основной БД, и в журнале изменений); языки запросов реляционных СУБД не приспособлены для работы со временем.
Существует отдельное направление исследований и разработок в области темпоральных БД. В этой области исследуются вопросы моделирования данных, языки запросов, организация данных во внешней памяти и т.д. Основной тезис темпоральных систем состоит в том, что для любого объекта данных, созданного в момент времени t1 и уничтоженного в момент времени t 2, в БД сохраняются (и доступны пользователям) все его состояния во временном интервале [t1, t2].

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

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

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

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

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

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

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

· Интегрированные или федеративные системы и мультибазы данных

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

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

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

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

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

· Распределенные СУБД

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

· Синхронизация доступа к данным

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

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

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

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

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

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

· Поддержание копий данных в нескольких узлах сети

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

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

· Фрагментация объектов БД

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

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

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

· Алгоритмы выполнения реляционных операций

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

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

Заключение

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

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

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