Значения аттрибутов

[Юрицын Андрей]

Работая фиксированными значениями атрибутов мы столкнулись с проблемой.

Имеется атрибут, значение которого можно выбирать только из списка. Например стадии проектирования "П", "Р" и т. д.. Если одно из значений атрибута реализовано хотя бы в одном объекте то удалить его невозможно.

По ошибке мы ввели в список возможных значений атрибута еще одно и использовали его для объектов. После обнаружения ошибки у этих объектов значение атрибута было изменено на верное. При попытке удаления неверного значения из списка возможных система сообщает об ошибке: "Значение ... не может быть удалено, т.к. на него есть ссылки в базе данных"

Поиск объектов со злосчастным значением атрибута выдает пустой список, однако Lotsia упорно заявляет о невозможности удаления из-за наличия ссылок в базе данных!

Что с этим можно сделать

[LTH]

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

[Юрицын Андрей]

Спасибо за помощь!

Печально однако, что Lotsia накладывает достаточно жесткие ограничения на процесс проектирования. Эти вещи:

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

делают невозможным сохранение базы данных в чистоте от подобного "мусора" в условиях "горячей" разработки структуры . Если это сделано для обеспечения защиты целостности БД, то не оправдывает, на мой взгляд этой цели: администратор - человек ответственный. В крайних случаях можно использовать резервный backup БД.

Для кого пишу, сам не знаю

[LTH]

Печально однако, что Lotsia накладывает достаточно жесткие ограничения на процесс проектирования. Эти вещи:

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

делают невозможным сохранение базы данных в чистоте от подобного "мусора" в условиях "горячей" разработки структуры . Если это сделано для обеспечения защиты целостности БД, то не оправдывает, на мой взгляд этой цели: администратор - человек ответственный. В крайних случаях можно использовать резервный backup БД.

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

Для кого пишу, сам не знаю

Для коллег? Для разработчиков? Или для всех нас. Как Вам больше нравится.

[Anderyt]

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

[Anderyt]

мысль не совсем в тему этой темы , но тем не менее... недавно при создании типа атрибута обратил внимание на поле Связь. там два значения - Объект и Проект... ЧТО ЭТО ТАКОЕ? у нас все атрибуты со связью Объект, может быть поэтому приходится "наследовать" атрибуты через БД (см. предыдущее сообщение от меня же) есть у кого нить опыт работы со связью атрибута Проект? поделитесь плиз! а то какое то чувство закралось.... может.... может у НАС ВСЕ СДЕЛАНО НЕПРАВИЛЬНО???? думаю, попробую рано или поздно этот тип связи, но может у кого то уже что то получилось?

[Natalia]

мысль не совсем в тему этой темы , но тем не менее... недавно при создании типа атрибута обратил внимание на поле Связь. там два значения - Объект и Проект... ЧТО ЭТО ТАКОЕ? у нас все атрибуты со связью Объект, может быть поэтому приходится "наследовать" атрибуты через БД (см. предыдущее сообщение от меня же) есть у кого нить опыт работы со связью атрибута Проект? поделитесь плиз! а то какое то чувство закралось.... может.... может у НАС ВСЕ СДЕЛАНО НЕПРАВИЛЬНО???? думаю, попробую рано или поздно этот тип связи, но может у кого то уже что то получилось?

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

[Anderyt]

У нас сейчас все атрибуты объектные, их приходится наследовать при создании каждого объекта (а все объекты создаются действиями), так что структура более менее описана Пример с девушкой многое объясняет , но и порождает вопросы. Обычно девушка в каждый момент времени замужем за одним человеком, и "проектный атрибут" может быть только один. а как быть с объектом Парти ?он может быть сразу в нескольких местах одновременно, что будет с его проектным атрибутом? смотря как смотреть (смотря через какой проект)? и еще.. вот например атрибут Обозначение. у объекта на одном из верхних уровней он может выглядеть как "1234-УКПГ", на следующем уровне - "1234-УКПГ-1", и далее - "1234-УКПГ-1-АС". можно ли в таком случае из обозначения сделать проектный атрибут? тогда придется для каждого нового уровня задавать новое значение этого атрибута в соответствии с принятыми правилами... такое возможно?

[Alxd]

Я последнее время немного отошел от администрирования Lotsia PDM Plus, но скажу одну вещь...

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

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

Собственно сама процедура получает, как мне помнится, ID объекта и ID типа. Остально можно получить из базы данных.

Нашел процедуру в Sybase Central.
ALTER function LSDBO.XXX_GetMarkaValue(in @type_id numeric(18), in @obj_id numeric(18)) returns varchar(2000)

Вызывается она из аддона и передает необходимые параметры. Далее процедура сама разбирает какой объект ей попался , что у него за родители , с кем они дружат и куда ходят.

После чего, на базе полученного анализа формируется обозначение. Причем сами значения частей обозначения берутся из родителей.

Например: объект "Площадка" атрибут "Обозначение" значение "КЮ". Это самое КЮ и войдет в обозначение. И так с каждым предком.

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

[Anderyt]

Свелось все к написанию процедуры в базе данных и маааленького аддона, который вызывается при попытке модификации атрибута!

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

[Alxd]

а у самих предков как выглядит Обозначение? у той же площадки - просто "КЮ", или что то есть вначале?

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

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

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

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

[Anderyt]

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

[Alxd]

Все ясно. Под "процедурой" я понимаю понятие Лоции "шаблон". Это так. На всякий случай пишу.

Твой подход не так прост. Скажу так, не соответствует

лучше день потерять, потом за пять минут долететь!

Мне так кажется

[Anderyt]

Твой подход не так прост. Скажу так, не соответствует

лучше день потерять, потом за пять минут долететь!

Мне так кажется

нормальный подход!!! мультики надо правильные смотреть!!!
а прикинь, поторопишься, потом переделывать????

[Alxd]

Этот мультик у меня на почетном месте в каталоге mp4!
А ведь страус в конечном счета так и не поел! Гриф запарился, а страус своей дорогой пошел...