Форум режимщиков

triana писал(а) Wed, 14 May 2008 16:46

Пристегиваю файл с Правилами кодировки. Имея правила - можно децентрализоваться. с ГУИДом - нет. Если интересно -могу выложить и теорию, схему связей сущностей и т.д.

А что будет, если одна энергосистема перейдет в другое ОЭС?

Схема связей и сущностей в чем исполнена?

Добрый день!



При формировании кода используются следующие признаки:

1. Иерархия управления: ОЭС Центра - Орловская ЭС

2. Административное деление: автомобильный код территорий России

3. подвиды:

001 – системообразующая ПС

002 – распределительная ПС

003 – потребительская ПС

то же для линий



Так вот, даже не касаясь всего остального, все эти три пункта НЕУСТОЙЧИВЫ. То есть, если рассматривать объект во времени, то он может менять свои признаки, как по пункту 1, так и 2 так и 3.

Интересно узнать, предусмотрели ли Вы такие переходы во времени? Как при этом будет работать поиск? Ведь объект поменяет свой код, возможно не один раз за время эксплуатации?



Удачи!



PS: Почему такие решения принимаются? Ведь эти грабли давно известны...

PSS: Предложенный код явно противоречит IEC61346...

Есть еще одно правило: после того, как составлен уникальный код по логическому правилу, он не меняется. Екземпляр может изменять свою подчиненность, для этого существуют в базе поля типа - parent. Таким образом просто перетащить Нижегородскую ЭС в ОЭС Средней Волги, и их объекты тоже.

Т.е. объект-код после рождения изменяться не может, он может только умереть. Кстати, применена схема "жизни" -

поле DATE_ACT - дата рождения

поле DATE_end - дата смерти и это просто решает т.н. темпоральность -возможность хранить все исторические данные и "прыгать" назад или вперед в нужный момент времени.

Схема нарисована в VISIO, без UML - разработчики Справочников рисуют в UML...

Отвечаю - поиск работает идеально.

Простите, еще раз - код не меняется.

а насчет PS - это не решения, это реализация...

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



Это именно решение! Кривое решение можно прекрасно реализовать, и оно некоторое время даже будет работать...

А дальше будет танец на граблях!



Удачи!

Код не меняется, и противоречие не наступает.

Представьте себе ситуацию, когда подстанция, например, поменяла свой признак- стала из потребительской - системообразующей.

Она же не перестала быть сущностью - подстанцией. И никуда не переехала с данного земельного участка... И присоединенные линии у нее остались...

Соотношения с управлением, территорией - изменяются, но зачем их менять в коде?

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

Удачи!

triana писал(а) Thu, 15 May 2008 17:29

Код не меняется, и противоречие не наступает. Представьте себе ситуацию, когда подстанция, например, поменяла свой признак- стала из потребительской - системообразующей.

Представил. Я как программист даю запрос: дай мне все системообразующие ПС (запрос даю по коду!)? Получу ли я в ответе "старую" потребительскую ПС?

Цитата:

Она же не перестала быть сущностью - подстанцией.

Согласно Вашей логике - перестала, так как если её заново проидентифицировать в соответствии с Вашей же методикой, то у нее будет другой идентификатор. То есть "правильность" идентификатора зависит от времени идентификации.

Цитата:

И никуда не переехала с данного земельного участка...

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

Цитата:

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

А Вы смотрели СИМ? Там эти вопросы решены изящно и теоретически безукоризненно.



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