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

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

Forums: 

Изображение пользователя st.

ОКАТО?

Как насчет использования ОКАТО (Общероссийский классификатор объектов административно-территориального деления)?

У меня был давний, но успешный опыт с ОКАТО. Структура дерева представляется материализованными путями.

Изображение пользователя ipanshin.

А что значит интересуюсь?

Я , например, вообще против справочников. При одном упоминании слова "справочник" я представляю будку справочного бюро, которая стояла у Московского вокзала. Там сидела бабка и давала справку. Я думаю, если поковыряться в голове этой бабки, то как раз и получишь типовую схему или структуру населения, населенных пунктов и прочих достопримечательностей.

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

И скучно, и грустно
И некому руку подать
В минуты душевной невзгоды
Желанья? Что толку желать?
А годы уходят, все лучшие годы...

Это Сергей Есенин
Да, я тоже интересуюсь. А на что уходят лучшие годы?

Гы Гы Гы

Ну, а если сурьезно, то я сделал такие таблицы: Obl, Sity 'город областного подчинения', Region 'район', Town 'город регионального подчинения', SelsovetSity 'сельсовет _деревня подчинененная Сити', SelsovetReg 'сельсовет _деревня подчинененная региону', PoselokSity 'подчинененный Сити', PoselokReg 'сельсовет _деревня подчинененная региону'. Это таблицы справочники, причем поселки, деревни, города могут быть агрегатами как региона, таки и город или Сити. Поэтому пользоваться таблицей классов не представляю как. На карту наносить может и придется, но пока задача другая - определить потребителей электроэнергии области с привязкой к энергообъектам и населенным пунктам. Привязку потребителей во избежание "многие к многим" к перечисленным справочникам сделал через промежуточную таблицу связки с полями ID_potreb, ID_Sity, ID_town, ID_SelsovetSity, ID_SelsovetReg, ID_PoselokReg, ID_PoselokSity. Думаю, может создать такую табличку для связи с каждой таблицей справочником

Изображение пользователя st.

Свести в одну таблицу

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

А как же агрегаты?

А как быть с тем, что поселокСити является агрегатом Сити. А идентификатор_населенПункта имеет атрибуты (кортеж)? Есть примеры? В принципе, догадываюсь, что это возможно, на всех вебсайтах, когда регаюсь я ведь в одном окне могу выбрать и регион и городСити.

Изображение пользователя ipanshin.

определить потребителей электроэнергии области с привязкой к эне

Прямо вытягиваешь инфу. Надо предложить это как вид спорта:"вытагивание инфы" и сделать его олимпийским видом.

1. вариант
А у меня отдельный индивидуальный договор с энергопоставщиком, я сдаю дом, который арендовал, субарендатору, который прописан на сейшельских островах. При этом ни хрена не понимаю по-русски. Вопрос: могу ли я быть включен в Вашу систему безболезненно, если я сам прописан в приморском крае, но живу рядом с ельцовским с/советом около Е-бурга?

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

все возможные варианты

Да, Ваш вариант 1 заставил задуматься. Надо бы и письма писать и электроэнергию по районам считать!
Думаю следует различать два адреса - один для принимающей энергоустановки (место установки вводного электрощита, ТПухи, РПэхи), второй - почтовый :) для арендодателя с Сейшельских островов. Но тогда еще вырисовывается таблица электроустановок потребителя + таблица с упрощенными вариантами этой электроустановки. Например,для Товарищества застройщиков, жилищного кооператива эти адреса, конечно, совпадут .

Изображение пользователя ipanshin.

Адрес

Да, понятие АДРЕСА здесь основополагающий класс объектов, который будет принадлежать любому другому объекту, имеющему территориальную, административную, формальную или фактическую принадлежность. И адрес это не простое varchar поле в таблице, а полноценный класс, который обеспечивает операции пересечения и объединения, как со стороны поставщиков, так и со стороны потребителей электроэнергии. Ну и т.д. ...
Короче говоря "use case" в студию.

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

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

Современные счетчики электроэнергии обеспечивают полноценный интерфейс их программирования и опроса состояний по модему или по энерголиниям. Это, как я понимаю обратная сторона БД?

О будущем

Пока в мои планы создание билинговой системы не входит, это пусть наш оператор коммерческого учета покупает, кстати, вроде купил ужо какую-то разработку. У меня узкая режимная задача + графики аварийного ограничения. Прошу посоветовать буквари путные (для простых смертных типа) по проектированию бд, а лучше учебные заведения. Спасибо.
Насчет современных счетчиков - это, пока, только начинается, в основном на крупных энергообъектах (подстанции 110/10, даже не РП). Называется эта беда АСКУЭ или АИИСКУЭ. Почему беда, разговор не в рамках форума. Думаю, лет через дцать система придет к "миноритарным" потребителям :)

Изображение пользователя ipanshin.

буквари путные

К букварям путным отношу опыт только, который излагаю чрезвычайно плохо в силу отсутствия свободного времени. Вот позапрошлогодний мой проект http://nexus.arbinada.com/UchetSyr'ja?v=ubk. Вот проект прошлогодний http://www.docsvision.com/index.phtml?Na... (из списка смотри модуль репликации). Сейчас участвую в новом проекте, в рамках которого конвертирую скрипты БД доксвижена на MySql, Oracle ну и м.б. PostGre. Но для того, чтобы передать знания о написании, нужно рассказать кусок своей жизни, а может быть и всю. Пусть СТ что-нибудь покажет написанное. У него лучше это получается.

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

АСКУЭ или АИИСКУЭ да это круто. Но нас не удивишь. В свое время я победил ИКСРФ, когда интегрировал ПУКФ ГАС "Выборы". Думаю, что ваша система может заработать через год. А через два станет полноценной АСКУЭ или АИИСКУЭ. Успехов.

Изображение пользователя st.

По поводу счетчиков

В развитых странах дела обстоят проще, вот пример EDF (Electricité de France). Деньги за электричество списываются автоматически с банковского счета потребителя ежемесячно. Сумма расчитыватся исходя из годового потребления. Раз в год снимают показания счетчика (бумажка по почте или приходит сотрудник со специальным лаптопом) и пересчитывают. По-моему, это гораздо дешевле, чем ставить в каждый домашний счетчик робота-автоответчика.

Изображение пользователя ipanshin.

развитые vs. недо

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

КЛАДР?

КЛАДР?