Проектирование пространственной базы данных.

[x77]

remedius, забейте, это я так радостно реагирую на то, что "также прав".

разработчик - человек сделавший базу (вы, в данном случае)

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

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


далее по сабжу.

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

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

или

2. писать UDF, которая распарсит XML "внутри" запроса, и одним запросом получать готовый список нужных фигур.

оба варианта сложны в реализации (по сравнению с тривиальным запросом с условием в WHERE clause) и достаточно медленны по произодительности. поэтому я бы всё таки подумал о том, чтобы делать нормальную реляционную модель со связью "один-ко-многим".

ещё мне не понятно-таки, что это за пользовательские таблицы, и зачем пользователю их создавать?

[remedius]

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

[remedius]

remedius,
ещё мне не понятно-таки, что это за пользовательские таблицы, и зачем пользователю их создавать?

Ну допустим есть карта Москвы. Она состоит грубо говоря из слоев (табличек). среди них есть пространственные, а есть и нет. Вы, как я понимаю предлагаете статично сделать эти все таблички. А если появится новый слой - например воздушные дороги. Кто займется воодом нового слоя? Тот, кто знает язык sql и вручную полезет и создасть еще одну табличку? Я видела это так: предоставляется два интерфейса по аутентификации: просто для пользователя, который работает с набором слоев (там например, показать ему все ночные кафе близ ВДНХ), и для пользователя, который имеет право создавать свои слои.

[x77]

remedius, хых. а зачем XML для ввода? ну вот решил пользователь нарисовать проекцию дивной статуи Зураба Церетели "Слеза печали" (народное название менее торжественно, но гораздо более ёмко) на гиперболоид вращения. а потом изобразить это всё на плоскости. он тыкает на некую педаль в интерфейса, скажем, "начать фигуру". ему становится доступен ряд других педалей: "линия", "ломанная", "овал" и т.д. тыкая поочерёдно на разные педали он изображает то, что, в его представлении, соответствует поставленной задаче. в процессе действа вся эта инфа (по уже нарисованным и рисуемым в данный момент фигурам) хранится в неких локальных переменных (собственно, можно и XML, но оно того не стоит, ради всякой муры толпу интерфейсов поднимать). когда юзер обессилит, он нажмёт на педаль "закончить фигуру". после этого стартуется транзакция, и из локальных переменных инфа перекочует в базу. если в процессе перекачки проблем не возникнет - транзакция будет завершена. собственно, вот и весь ввод.

или я опять чего не понимаю?


по поводу слоёв.

Типы_Слоёв
--------------------------
Идентификатор__типа_слоя
Наименование_типа_слоя
Описание_типа_слоя
...

Слои
---------------------------
Идентификатор слоя
Идентификатор_типа_слоя
Наименование_слоя
...

Фигуры
--------------------------
Идентификатор_фигуры
Наименование_фигуры
....
Идентификатор_слоя
....



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

динамическое создание таблиц в процессе эксплуатации - это безумие.

[x77]

Вы, как я понимаю предлагаете статично сделать эти все таблички

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

[x77]

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

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

а вы, насколько я понимаю, собираетесь для 10 слоёв создавать десять таблиц с фигурами? ещё раз - это безумие.

[remedius]

Стоп, Вы говорите о фигурах, т.е. о ГИС  объектах - так они у меня так и храняться в статическом наборе таблиц. Если Вы говорите про что-то другое, то я не поняла.

[remedius]

(а вообще можно и на ты -  не такая я уж и взрослая:) -  а то как-то неловко....

[Dimka]

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

А...

Прямо-таки процедуры для создания пользовательских таблиц??? Или всё же процедуры для модификации пользовательских таблиц? Надеюсь, вы не собираетесь запрещать пользователю работать с его базой данных так, как ему вздумается?

Но я считаю, никаких прав таблицы ГИС он не должен иметь.

Но считать мало. Администратор баз данных обычно имеет право (особенно системный администратор SQL Server). Это факт! Его можно игнорировать, пытаясь "разрулить" права. Но ни один администратор: а) не заподозрит, что ваша система пытается его ограничить; б) даже не заметит этого. И именно исходя из этого факта следует, что вся эта бурная деятельность экономически не оправдана: разработчик работал, затратил время, а практического эффекта от этого нет. Единственный эффект - учебный, вы немного познакомились с задачами управления правами в СУБД. Но теперь, когда вы уже знакомы с этими задачами, продолжать ими заниматься в этом проекте, признаться, смысла не вижу.

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

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

или

2. писать UDF, которая распарсит XML "внутри" запроса, и одним запросом получать готовый список нужных фигур.

Для SQL Server 2005 это уже не актуально. Он равно работает как с реляционными данными, так и с XML (структура которого не противоречит соглашениям). Т.е. на уровне своего движка умеет делать запросы к XML-документам без потребности реализации парсинга разработчиком. При этом производительность примерно одинаковая, что и при работе с таблицами (хотя производительность работы с таблицами упала раза в 1,5-2 против 2000).

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

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

(а вообще можно и на ты -  не такая я уж и взрослая:) -  а то как-то неловко....

Только если взаимно Мы тут тоже не то, чтобы старые.

[Dimka]

Кстати, мой вопрос о способе установки связей между новыми/обновлёнными пользовательскими объектами и объектами ГИС остался не раскрыт. Как это планируется делать?

[remedius]

Ну Вы  это Вы, хотя бы потому что уважать есть за что...А меня пока не за что:) Вот свояю, что-нити дельное, тогда может и начну на Ты. Ну правда если Вы этого так хотите, то можно и на ТЫ...(дело тут совсем не в возрасте...

Так, начнем все с начало (уж извиняюсь за тупоголовость). Теперь я уже точно осознала, кто такой администратор. Он тут совсем не причем, я имела ввиду того, кто будет создавать таблички (НЕ ГИС имеется ввиду). Т.е. данному человеку нужно предоставить все права создания табличек на уровне sql запросов? или какой интерфейс должен иметь пользователь - создатель своей БД? .логичнее наверно было для него написать приложение, но что оно должно иметь дело? Необходимо удовлетворить следующие требования:
1. Данный пользователь должен иметь право создавать таблицы
2. Данный пользователь должен иметь право делать их пространственными, т.е. связывать с пространственными данными (я предлагала это сделать путем выбора xml файла,описывающий геометрию и парсить его на клиенте, после чего последовательно вызвать соответсвующие хранимые процедуры.
3.НО я так понимаю, он не должен иметь доступ к таблицам ГИС, которые будут зранить структуру геометрии.

[remedius]

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

[Dimka]

Ну Вы  это Вы, хотя бы потому что уважать есть за что...А меня пока не за что:)

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

можно и на ТЫ...

Только, просьба, маленькими буковками

Он тут совсем не причем, я имела ввиду того, кто будет создавать таблички (НЕ ГИС имеется ввиду).

Так тот, кто создаёт таблички, и есть администратор. Лишь в подавляющем меньшинстве случаев кому-то предоставляются права модификации базы без всех прочих прав (исполнения хранимых процедур, получения/модификации данных). И не важно, какие это таблички - ГИС или пользовательские.

Т.е. данному человеку нужно предоставить все права создания табличек на уровне sql запросов? или какой интерфейс должен иметь пользователь - создатель своей БД? .логичнее наверно было для него написать приложение, но что оно должно иметь дело? Необходимо удовлетворить следующие требования:
1. Данный пользователь должен иметь право создавать таблицы
2. Данный пользователь должен иметь право делать их пространственными, т.е. связывать с пространственными данными (я предлагала это сделать путем выбора xml файла,описывающий геометрию и парсить его на клиенте, после чего последовательно вызвать соответсвующие хранимые процедуры.

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

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

Что тогда можно и нужно сделать?

Это надо сформулировать...

[Dimka]

Значит, рекомендации:

1) Права доступа к своей собственной базе данных определяет сам пользователь. Вообще исключить из сферы контроля ГИС-приложения этот раздел.

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

3) Ограничить набор хранимых процедур операциями: связи пользовательских данных и ГИС-данных, запросов ГИС-данных. Если приложение будет позволять выводить на картах различные данные пользователя, то продумать форму настройки запросов. Чётко определить операции, необходимые для работы приложения, а также отношение этих операций к объектам базы данных (например, для каких таблиц нужно разрешить запросы, для каких хранимых процедур нужно разрешить исполнение). Предоставление соответствующих прав - в общем случае задача администратора базы данных. Можно в рамках программы-инсталлятора предложить типовое решение (создание собственного пользователя, роли в базе данных, прописывание прав по умолчанию для известных объектов), но это не должно быть единственным возможным решением - пользователю необходимо предоставить свободу выбора использования этого типового решения или конфигурации прав вручную.

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

Ещё одно решение - создание трёхуровневого приложения: СУБД + сервер приложений + клиентские приложения. Тогда средний уровень сервера приложений будет инкапсулировать всю работу с СУБД, предоставляя клиентам лишь некий API (например, на базе веб-сервисов, CORBA или с помощью DCOM) и реализовывать собственную систему безопасности. Но это более трудоёмкое и менее производительное решение.

[remedius]

Т.е. предлагается, что пользовательские таблички и мои ГИС - это разные БД? И меня не должно волновать создание пользовательской БД. А фактически только связь пользовательких табличек с ГИС? правильно я поняла?

[remedius]

+<<Например, "Модификация ГИС-таблиц запрещена." >> Это имеется ввиду путем ограничения прав? или путем оговорки в документации?

[Dimka]

Т.е. предлагается, что пользовательские таблички и мои ГИС - это разные БД? И меня не должно волновать создание пользовательской БД. А фактически только связь пользовательких табличек с ГИС? правильно я поняла?

Не понял вопроса... Я правильно понимаю, что ГИС-система "крепится" к некоторой заранее не определённой на этапе разработки базе пользователя? Т.е. речь не идёт о некой конкретной справочной системе вроде карты маршрутов городского автотранспорта - той, данные (или хотя бы их структура) для которой заранее определены. Если так, то да. Не обязательно отдельной БД, можно самостоятельным подмножеством таблиц, встраиваемым в пользовательскую БД.

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

Это имеется ввиду путем ограничения прав? или путем оговорки в документации?

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

[remedius]

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

[Dimka]

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

Но все-что я могу предоставить процедурами, это ввод поточечно. Но это по-моему достаточно не удобно.

Удобно для кого? Твоё приложение будет написано соответствующим образом, пользователь (считается) работает в основном с приложением. Захочет написать своё приложение, использующее таблицы ГИС - воспользуется процедурой. В конце концов, не вручную же он эти точки вводить будет с консоли . Объём сетевого трафика при нескольких вызовах одной хранимой процедуры в сравнении с передачей XML будет одного порядка. Если пользователь захочет вводить географические данные из каких-то своих файлов, ты всё равно заранее не знаешь, что это за файлы, какой формат и структуру имеют. Опять же, это будет являться задачей пользователя - создаст он какой-нибудь DTS-пакет и загрузит с помощью него свои данные (благо DTS-пакеты создаются в визуальном редакторе SQL Server, и если не требуется сложных преобразований данных - написания скриптов преобразования записей, создать эти пакеты может любой "продвинутый" пользователь).

[remedius]

1.А как обычна данная надстройка "Крепится" к пользовательской БД? Это делается вручную? (например, по очереди открываются sql запросы и выполняются на сервере?, ведб заранее не известно к какой БД будет крепиться данная надстройка)
2. Когда-то мы тут осуждали библиотеку UDF(например на С++), а может у Вас есть пример под MSSQL? Не могу найти, с каким интерфейсом должна написана быть библиотека, чтоб потом ее понял SQL Server.

[Dimka]

1.А как обычна данная надстройка "Крепится" к пользовательской БД? Это делается вручную? (например, по очереди открываются sql запросы и выполняются на сервере?, ведб заранее не известно к какой БД будет крепиться данная надстройка)

Либо поставка SQL-скрипта установки, либо прямо в программе установки выбирается сервер, БД и на них выполняется скрипт установки - автоматически.

В качестве примера можешь посмотреть такой продукт, как MS Reporting Services - он одновременно является надстройкой над SQL Server и IIS. Идёт в комплекте поставки SQL Server (в сложных версиях - кажется от Standard и более мощных Developer, Enterprise и т.д.) Предоставляет как пользовательский, так и программный веб-интерфейс. В качестве исходных данных для построения отчётов использует пользовательские базы данных - подключается к ним.

2. Когда-то мы тут осуждали библиотеку UDF(например на С++), а может у Вас есть пример под MSSQL? Не могу найти, с каким интерфейсом должна написана быть библиотека, чтоб потом ее понял SQL Server.

Нет, у меня нет примера внешней UDF. Я вообще внешними хранимыми процедурами и функциями не пользовался - ни разу не понадобилось. До сих пор всё, что нужно, удавалось реализовать с помощью T-SQL. (Включая обработку (парсинг) XML, статистические расчёты, запросы к LDAP-серверам, сбор данных из гетерогенных источников, рассылку почты, периодически выполняемые задачи, работа с базами данных по протоколу HTTP через соответствующий ISAPI (проще говоря, плагин к IIS).)

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

[remedius]

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

[Dimka]

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

Чего хотят увидеть/получить преподаватели? (Или, как звучало изначально задание на эту работу?) И как с этим желанием соотносится функционал полученного изделия? (Лучше в таблице по графам: Требование; Функционал/Способ, позволяющий решить задачу; Степень соответствия.)

P.S. Только в требованиях писать надо реальные требования преподавателей, а не собственные домыслы.

[remedius]

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

[Dimka]

нас совсем не учат постановки задачи,нас учат учиться...

Главное, что не мешают учиться

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

нужно преподнести нечто своеобразное, эффектное

Если вопрос ставится так, то, следовательно, существует масса единообразного и не производящего впечатление. В таком случае нужно описать это единообразное и "найти 10 отличий" Также определить в проекте уникальные фичи для пущей эффектности.

стандарная работа - это интернет магазин.

Ну вот, первое отличие: твоё изделие - не магазин

Могут и 3 влепить

Без паники

[remedius]

Что есть на сей день? - Есть пространственное расширение, которое хранит геометрию во внутреннем представлении в виде набора табличек, также хранит их mbr и предоставляет интерфейс ввиде хранимых процедур, по перемещению объектов, выдачи mbr и т.д. - все достаточно примитивно.
Что дальше? - это расширение предоставляется администратору, который настраивает права и создает таблички  с геометрией для юзеров, посредством интерфейса. (кстати, ввод объекта у меня пока осуществляется с помощью xml описания объекта)
Итого, времени осталось совсем чуть-чуть (~2 недели), а осталось написать клиентское приложение, которое просматривает данные таблички в виде нарисованных фигур и с помощью которых можно посмотреть также инфу об объектов, посмотреть их границы и с возможнотью их перетаскивания. В принципе как все это делать, я знаю. И что самое главное, осталось придумать, что это будут за объекты и ввести их в БД (скорее описать в виде xml). Но идей совсем мало, одна из которых - это модель комнаты.
Выводы: с моей точки зрения, все достаточно примитивно (с интеренет магазином, мне трудно сравнивать), видимо надо идти к преподавателям наименее разбираюимся в данной области. Соответсвенно от меня требуется красота.
Итого, вопрос остается открытым: Есть идеи?
Спасибо

[Dimka]

Красота - это скверно, т.к. 2 недели всего.

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

Может проще будет работать со статическими данными. Например, карта города/района/местности с сетью дорог? На ней решать задачи поиска маршрутов или размещения остановок. Из динамических объектов там будут только линии и точки. Самые алгоритмы отыскания маршрутов - вещи сугубо математические, поэтому не будут требовать длительной отладки и тестирования (в отличие от навороченного GUI).

[remedius]

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

Да, еще водлнует пару вопросов.
1.Когда  говорится о топологии объектов, что  подразумевается?
2. Следует рассматривать перемещение на уровне всего объекта, или точки?

[Dimka]

один оъект может содержать другой

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

Может просто какую-нибудь модель 3д взять?

Хм... комнаты, 3D-модели... А причём здесь ГИС?

1.Когда  говорится о топологии объектов, что  подразумевается?

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

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

2. Следует рассматривать перемещение на уровне всего объекта, или точки?

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

[remedius]

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

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

Хм... комнаты, 3D-модели... А причём здесь ГИС?

Не причем. Просто это красиво+ можно показать структуру хранения сложного объекта.

Также можно в добавок еще один пример показать. Что-нибудь демонстрирующую сохранение топологии объектов, например при перемещении.

Как я понимаю, существует жесткая и гибкая топология (это когда масштаб объекта сохранятеся и когда нет). так?