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

[remedius]

эээ нет, я так поняла что данные надо хранить все-таки не в одной системе координат, а по крайне мере в одной проекции (например Долгота/Широта). Да, еще если взять не конкретные точки, а объект, описанный точками, то если он изначально был в какой-нить африканской системе координат зарегистрирован, то при трансформации его, к примеру, в систему координат для России, мы при отображениии можем его просто не увидеть. Так что с этим еще придется поморочиться.

[Dimka]

а по крайне мере в одной проекции (например Долгота/Широта). Да, еще если взять не конкретные точки, а объект, описанный точками, то если он изначально был в какой-нить африканской системе координат зарегистрирован, то при трансформации его, к примеру, в систему координат для России, мы при отображениии можем его просто не увидеть.

Ничего не понял. Система координат "долгота-широта" - это полярно-сферическая система координат, абсолютно одинаковая как для России, так и для Африки, и даже для Марса.

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

[remedius]

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

[Dimka]

http://gis-lab.info/docs/giscourse/08-coords.html

[remedius]

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

[Dimka]

Логично наверно мои таблички спрятать как системные.

Малость не понял. В терминах СУБД системные таблицы - это собственные таблицы СУБД (для работый самой СУБД), всё прочее - пользовательские таблицы. Т.е. зачем пользовательские таблицы "прятать"? И зачем пытаться сделать их системными?

Где можно почитать как пишутся библиотеки для СУБД?

Что такое "библиотека для СУБД"? Реализация так называемого Data Layer в приложении?

[Igel]

Брр... почитал - такая каша.
Сравнил со своими высказываниями - как же трудно меня понять!
Вопросы:
1. Цель курсовой - сама задача - без тонкостей реализации, "Пространственных" баз, проекций, точностей и прочей деталировки?

[remedius]

dimka, ммм..ну таблицы, которые будут использоваться для хранения пространственнных даных (например описание, полигона и др. данных). Пользователю, который будет составлять свою БД не должен о них ничего знать,  я так полагаю.
Например:
CREATE TABLE cola_markets (
mkt_id NUMBER PRIMARY KEY,
name VARCHAR2(32),
shape MDSYS.SDO_GEOMETRY);
Я понимаю, пользователю не нужно знать, как храниться поле shape...
А библиотека собственно говоря,  предназанчена для  использовании таких таблиц на сервере и предоставления соответсвующих структур и функции (например, MDSYS.SDO_GEOMETRY) .
Я что-то не так поняла?

[remedius]

Igel, Цель курсовой: написать (самое главное) сервер, хранение и обработку данных, с поддержкой топологии. Ну и клиента для демонстрации работы с СУБД. Например,  можно создать БД, состоящих из примитивов и сдвинуть какой-либо из них. Результат должен быть соответсвующий. 

[Dimka]

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

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

MDSYS.SDO_GEOMETRY

Это чьё выражение? DB2? Если да - по DB2 советов давать не могу, не знаком.

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

[remedius]

dimka, Нет это функции Оракла, пространственное расширение.
Честно говоря, я мало что опоняла про реестр. Но я имею ввиду, что мне надо написать расширение для сервера, т.е. бибилиотеку. Чтоб когда юзер вызывал какие-либо функции (напирмер), то сревер не пугался, что у него их нет:), а обращался к этой бибилотеки грубу говоря. Привожу следующий пример, я думаю чтанет понятно:
CREATE TABLE cola_markets (
mkt_id NUMBER PRIMARY KEY,
name VARCHAR2(32),
shape MDSYS.SDO_GEOMETRY);

INSERT INTO cola_markets VALUES(
1,
’cola_a’,
MDSYS.SDO_GEOMETRY(
2003, -- 2-dimensional polygon
NULL,
NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3), -- one rectangle (1003 = exterior)
MDSYS.SDO_ORDINATE_ARRAY(1,1, 5,7) -- only 2 points needed to
-- define rectangle (lower left and upper right)
)
);

-- Return the areas of all cola markets.
SELECT c.name, SDO_GEOM.SDO_AREA(c.shape, m.diminfo)
FROM cola_markets c, user_sdo_geom_metadata m
WHERE m.table_name = ’COLA_MARKETS’ AND m.column_name = ’SHAPE’;

Вот, вопрос остается открытым...

[Dimka]

Вот, вопрос остается открытым...

Да, не подскажу.

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

[remedius]

Вот, вопрос остается открытым...

Да, не подскажу.
 Я думаю, рационально разнести содержание сущностей предметной области и их форму на карте по разным таблицам.

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

[Dimka]

Практически - очень плохо.

[Oldy]

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

[remedius]

А задача собственно говоря в следующем:
CREATE TABLE cola_markets (
mkt_id NUMBER PRIMARY KEY,
name VARCHAR2(32),
shape MDSYS.SDO_GEOMETRY);

INSERT INTO cola_markets VALUES(
1,
’cola_a’,
MDSYS.SDO_GEOMETRY(
2003, -- 2-dimensional polygon
NULL,
NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3), -- one rectangle (1003 = exterior)
MDSYS.SDO_ORDINATE_ARRAY(1,1, 5,7) -- only 2 points needed to
-- define rectangle (lower left and upper right)
)
);

P.S. пример из Оракла.

Так вот, говорят, что с массивами в FireBird трудно работать. А как еще реализовать что-то, на подобии данного примера - в голову не приходит:(

[remedius]

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

[Oldy]

О FireBird.
Да, с массивами в нем тяжеловато работать, но всегда существует возможность создать и подключить свои DLL с UDF позволяющими делать что угодно. Например вот это http://www.ibase.ru/d_udf.htm - ListUDF

С другой стороны чем BLOB не массив?

[remedius]

Хорошо, а тогда как будет это поле (например, MDSYS.SDO_GEOMETRY) отображаться в таблице?

[Dimka]

Хорошо, а тогда как будет это поле (например, MDSYS.SDO_GEOMETRY) отображаться в таблице?

BLOB по определению Binary Large OBject В двоичном виде. Запросы по таким объектам либо невозможны, либо, если можно добавлять внешние (не SQL) хранимые процедуры и функции, работать с помощью этих функций.

А почему объекты непременно хранить в этих структурах? Неужели просто пару-тройку таблиц не создать? Или считаете, слишком медленно будет работать?

[remedius]

А почему объекты непременно хранить в этих структурах? Неужели просто пару-тройку таблиц не создать? Или считаете, слишком медленно будет работать?

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

[Dimka]

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

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

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

В MS SQL Server 2005 добавлен новый тип данных xml, и движок сервера написан таким образом, что операции с XML-документами осуществляются наравне с операциями над реляционными таблицами. Сколь я слышал, где-то в Oracle таблица может быть типом столбца таблицы...

[remedius]

dimka, Да, XML это очень даже хорошая мысль.
интересно,  а если создавать свой структурированный тип данных (как в db2 например), то будет ли:
1.отображаться столбец ?
2. по нему осуществляться поиск ?
3.храниться данные внутри сервера, в виде блобов или таблиц?

[x77]

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

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

[Dimka]

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

Вот я тоже всё не могу понять, что от кого надо прятать...

[remedius]

 Хорошо, решено делать полностью реляционную модель, но тогда, чтоб не было N -ое количество вызовов типа AddPointToGeometry(), напрашиваются следующие вопросы:
1. Есть ли в sql понятие функции(процедуры) с неограниченным числом аргументов? типа f(int n,...);
2. Допустим, нет таких функций, тогда в принципе можно заменить аргументы типом данных строкоа. На сколько затратный данный способ. (ведь ее в принципе тоже нужно будет парсить, как и xml)
3.Можно ли проверять таблицу на наличии PK?(если да, то как.

[x77]

remedius, я отвечу с точки зрения FB, может быть, пригодится.

1. Нет. Это реализуется через UDF.
2. Совсем не затратный, потому что UDF, в т.ч. и с готовым набором функций для работы со строками, в .тч. и бесплатных - великое множество. а парсить переданную параметром строку всё равно придётся своими функциями, т.к. предоставляемый FB функционал для работы со строками - довольно ущербен. в этом смысле лучше сразу писать функции на UDF, которые будут сразу вставлять/менять данные.
3. можно, только зачем? не совсем понятно.

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

[remedius]

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

[x77]

вообще говоря, на уровне базы мы будем иметь две таблицы:

Фигуры
=============
Идентификатор_Фигуры (атоинкремент, ПК)
(вся остальная мура)


Координаты_Фигур
=============
Идентификатор_Узла (автоинкремент, ПК)
Идентификатор_Фигуры (ВК по таблице "Фигуры")
Абсцисса
Ордината

таким образом, формирование сколь угодно сложной фигуры сведётся к последовательному выполнению ряда процедуры вида AddPoint (Xn, Yn), где (Xn, Yn) принадлежат массиву типа TPoint (X, Y) от 1 до N, сформированному на стороне клиента (никак не базы). и я не вижу ничего страшного в том, чтобы в рамках одной транзакции данные по фигуре заполнялись несколькими вызовами одной и той же процедуры - это может иметь свои (и существенные) плюсы.

[remedius]

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