Я на чужой вопрос отвечу, ладно? :)

В Informix/MS SQL/Sybase/..., короче, во всех почти СУБД есть такое понятие, как "база данных", коих может быть много в пределах одного набора серверных процессов. "Внутри" базы данных находятся таблицы, индексы, которыми владеет какой-то пользователь, к каждой базе и к её объектам может быть разрешён уровень доступа пользователей и т.д. Т.е., "база данных" в данном случае - скорее логический, чем физический объект.
В Oracle такого нет. Database в Oracle - это чисто физическая штука. Под "базой данных" в Oracle подразумевается набор файлов на дисках сервера. Набор процессов и структур в памяти - это "экземпляр". Экземпляр при запуске ассоциируется с базой данных и предоставляет пользователям доступ к данным, находящимся в файлах на диске (в "базе данных"). Один экземпляр работает только с одной базой данных, хотя возможны варианты работы нескольких экземпляров сразу с одной базой данных (Parallel Server). На одной машине одновременно могут существовать и независимо работать несколько экземпляров и ассоциированных с ними баз данных.

Логическое деление, обеспечиваемое "базами данных", в Oracle осуществляется через "схемы" - совокупности объектов, принадлежащих каждому конкретному пользователю. Для доступа к объектам других пользователей необходимо использовать стандартную нотацию <имя пользователя>.<имя объекта> (если не определены синонимы). Имя объекта каждого типа (таблица, индекс,...) уникально в пределах схемы.

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

Конечно, с raw работает тоже. Я же сказал, что упрощённо всё написано :)

Вопрос никак не пойму - почему мне будет сложно заставить работать на одной СУБД несколько разных приложений? В некоторых случаях это может быть неоптимальным решением, но невозможным в принципе - очень и очень вряд ли (я чуть выше описал такой фантастический вариант).
ЧТО ИМЕННО, с Вашей точки зрения, может мешать сосуществовать двум приложениям в рамках одной СУБД?

Я, наверное, недостаточно подробно объяснил. Итак: как таковое понятие "схема" в Oracle не является сущностью, это всего лишь набор объектов, которыми владеет (которые, возможно, создал, хотя это не обязательно, объекты, при наличии привилегий, можно создавать и "от имени" другого пользователя) некий пользователь СУБД. Подключившись к СУБД, этот пользователь может обращаться к "своим" объектам напрямую, без указания имени пользователя-владельца (т.е., например, select * from table1), хотя, конечно, допустимо и с указанием владельца (select * from scott.table1). Как владелец, пользователь может давать привилегии (select, insert, ну и т.д.) на операции со своими объектами другим пользователям СУБД. Эти другие пользователи, в таком случае, обращаются к этим объектам посредством нотации <имя владельца>.<имя объекта>. Однако, эти пользователи могут создавать т.н. "синонимы", которые скрывают полное имя объекта (т.е. с указанием владельца). Синоним "виден" в схеме пользователя, его создавшего. Синоним, однако, не даёт никаких прав доступа, это просто другое имя объекта. Ближайший аналог синонима - симлинк в юниксах. Также возможно создание public-синонимов, которые видны всем пользователям СУБД. Синоним, естественно, может повторять имя объекта, на который ссылается (т.е., например, пользователь anna создаёт синоним, который называет table1, а он ссылается на scott.table1, при этом anna может сказать select * from table1, а селект пойдёт из таблицы table1, которой владеет scott).
Обычно всеми объектами одного приложения владеет один-единственный пользователь СУБД, обладающий необходимыми привилегиями на некие физические ресурсы СУБД (квоты на необходимые табличные пространства (в Informix - dbspace), процессорное время иногда, ну и т.д.).
Если приложение построено по двузвенной архитектуре, т.е., каждый конечный пользователь суть пользователь СУБД, то тогда владелец объектов приложения назначает каждому из конечных пользователей необходимые привилегии на свои объекты, а также создаёт public синонимы, через которые пользователи обращаются к нужным объектам СУБД. Впрочем, можно поступить проще и собрать все привилегии в роль, которую назначать пользователям, но такое не всегда возможно. Обычно такие задачи выносятся в отдельный скрипт, запускаемый администратором от имени владельца или, при наличии нужных привилегий, от своего имени.
Если приложение - трёхзвенка, т.е. авторизацией пользователей занимается приложение, а к БД коннекты идут от имени некоего специального пользователя, тогда, обычно, владелец объектов предоставляет необходимые привилегии этому специальному пользователю, а он создаёт себе синонимы для доступа по сокращённому имени.
Такая сложная конструкция необходима для обеспечения определённого уровня безопасности, для предотвращения намеренного или случайного удаления/порчи данных пользователем-не-владельцем.

Забыл добавить - владелец объекта может сделать с ним что угодно.