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

[remedius]

P.S. просто пока меня волнует сдача курсача, а потом уже дальнейшее осмысление данного продукта:) Поэтому ищу какое-нить эффектное решение показа геометрии и управление ею.

[Dimka]

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

Т.е. на деле всего лишь стоит задача написания редактора векторной графики?

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

Приложение будет существовать вне зависимости от смысла хранящихся в БД данных. Нужно определить тип этого приложения: или это редактор, или это просто визуализатор. Я думаю, что хороший и, главное, красивый редактор "с нуля" за две недели не сделать. Что я ещё могу сказать?

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

Ничего не понял. Ты не путаешь слова "топология" и "форма"? Если нет, то что такое "сохранение топологии объекта при перемещении" в контексте ГИС-объекта, состоящего из множества точек?

[remedius]

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

[remedius]

даже не смещение другого, а изменение его структуры ( так правильнее

[Dimka]

а что значит пользовательские объекты?

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

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

Изменение структуры - это количества точек, рёбер, граней? Хм... А, собственно, почему? Это же от задачи зависит. Если у нас есть модель стола со стоящей на нём лампой, то при перемещении/вращении стола по комнате лампа тоже перемещается в абсолютных координатах комнаты, но не перемещается в относительных координатах стола. Если у нас есть карта области, и областной центр решил поглотить лежащую рядом деревушку, то изменятся синхронно фигуры города и огружающего его района - граница между ними перенесётся, их площади изменятся, а фигура деревушки структурно перейдёт из одного "контейнера" в другой. А бывает так, что стоят в комнате два шкафа впритык друг к другу - можно считать, что они имеют общую границу; но шкафы можно пространственно разнести без ущерба для их формы.

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

[remedius]

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

Ок, тогда пердыдущее объяснение остается в силе. А что бы совсем сало понятно приведу пример:
update my_table
set graphics = AddGeometry(xml ) where id = 22;

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

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

[remedius]

Кстати, на счет графического визуализотора. Можно например воспользоваться directx. ДОстаточно красиво получиться:)

[Dimka]

Можно например воспользоваться directx. ДОстаточно красиво получиться:)

Не сомневаюсь. Только: а) нужно знать сам DirectX, б) нужно иметь в проекте те красоты, которые предполагается с помощью DirectX реализовывать. Из того, что на DirectX можно сделать "красиво", совершенно не следует, что так оно и будет...

[remedius]

Возможно, но попробовать думаю стоит. а) на directX приходилось писать курсовик. b)да, осталось найти фигуру, и как-нибудь автоматизировать ввод ее примитивов в БД:) всего ничего..Ладно, я еще подумаю...

[remedius]

Как обычно поступают: пишут хранимые процедуры обертки (например, для select * from mytable, ну или по сложнее чуть запросы) или запросы посылаются приложением?

[Dimka]

Разно. Обычно это является элементом архитектуры, внутренним соглашением проекта. Т.е. либо всё идёт через ХП, либо всё идёт непосредственно от приложения.

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

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

В любом случае собственно приложение (прикладная его часть) отделено от механизма обмена данных с СУБД посредством введения Data Layer или даже промежуточного Application Server - некоего сервиса, доступ к которому осуществляется по  DCOM, CORBA или как к веб-сервису. Собственно приложение получает/сохраняет/удаляет данные при помощи API, состоящего из предметно-ориентированных объектов или структур и функций.

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

[remedius]

Курсач сдала, отл. Терь немного отойду, узнаю куда дальше развивать. Напишу.
Спасибо!

[Dimka]

Курсач сдала, отл.

Поздравляю!

Спасибо!

Всегда пожалуйста!

[x77]

вау

[remedius]

x77, На самом деле тут ничего удивительного нет. Все  только зависит от того, как ты это сможешь приподнести и от препа, и как не печально, совсем не зависит от того, что ты сделал. Одни чел просто взял у нас и перевел БД акссеса на скл, при этом сказав что типо акссес не актуален в наши дни. Соотношение это высказывание/преп привело к 5 . При чем тем же препам сдавал еще один чел, работающий в хп и т.д. сделал, что-то умное, за что ему и влепили 4:). Так что суди те сами...
P.S. А я препа долго подбирала...

[Dimka]

remedius, мне кажется, что всё тут тобою обсуждаемое, не столько для преподавателя делалось