Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура БД для хранения населенных пунктов / 25 сообщений из 29, страница 1 из 2
21.10.2006, 22:08
    #34072084
coderinside
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
Добрый вечер! Подскажите как организовать структуру для хранения населенных пунктов. Страна - > Область -> Город - то вроде вопросов нет, но ведь кроме Области может быть еще и АО, край... а вместо города - > Район -> Поселок. Сами города, поселки не нужны, нужна именно структура чтобы ее потом сами заполняли.
Куда смотреть?
...
Рейтинг: 0 / 0
21.10.2006, 23:02
    #34072118
Dik76
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
М.б. ОКАТО подойдет?

--
Dik76

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
21.10.2006, 23:08
    #34072126
Кот Матроскин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
Ну я бы сделал древовидную структуру "административная единица" +
справочник типов административных единиц ( то есть как раз "Страна", "область" и т.д). Если есть желание упорядочить данные, чтобы не могло быть страны внутри улицы :) - можно на этот справочник тоже наложить отношение 1:N "что может идти после чего", и при введении новой административной единицы проверять допустимость ее типа.
...
Рейтинг: 0 / 0
21.10.2006, 23:20
    #34072137
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
Насколько я видел, два основных подхода:

1. Древовидная иерархия типа той, что описал Кот Матроскин

2. Широкая таблица со всеми возможными полями (район, город, поселок итп), заполняются только некоторые из них. Ограничения целостности отсекают некорректные комбинации.
...
Рейтинг: 0 / 0
21.10.2006, 23:48
    #34072157
Кот Матроскин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
авторналожить отношение 1:N "что может идти после чего
Это я, конечно, глупость сказал, отношение должно быть M:N
...
Рейтинг: 0 / 0
22.10.2006, 22:39
    #34072724
coderinside
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
1. Страна характеризуется своим административным делением: республики, края, области, города федерального значения, автономные области, автономные округа.
2. Они образуют субъекты... Воронежская обл, Курская область, Алтайский край и т.д.
3. Те в свою очередь всегда состоят из городов и районов.
4. В районах находятся поселки, хуторы и пр.

Предлагаю сделать 7 таблиц:
СТРАНА
ДЕЛЕНИЕ
ДЕЛЕНИЕ_СТРАНЫ
СУБЪЕКТ
ГОРОД
РАЙОН
НАСЕЛЕННЫЙ_ПУНКТ

ДЕЛЕНИЕ_СТРАНЫ - таблица-связка для СТРАНА и ДЕЛЕНИЕ, т.к. "область" есть не только в России, но и например на Украине. ID этой таблицы - ключ деление какой страны выбрано. Затем по этому делению можно вывести все области например или республики. Выбрав какой либо субъект можно посмотреть какие города и районы в нем находятся, ну и т.д. Вроде нормально... Но не уверен. Какие есть мнения?
...
Рейтинг: 0 / 0
23.10.2006, 00:22
    #34072775
Кифирчик
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
ты расписываешь всё верно
ещё надо знать как может назваться на каждом "уровне" твой объект
АО-Автономная область, обл-область....город,посёлок,хутор,деревня....
это всё можно найти в классификаторах, поройся в консультант+
законодатели это всё давно продумали и утвердили
Скачай базу КЛАДР (..всероссийский классификатор адресов..) в электронном виде и поковыряй её. может проще её будет присабачить к программе, она и обновляется регулярно, весит кажется около 3 метров

Если говорить именно об административном делении, то с 2006 года появились такие еденицы как городские и сельские поселения. Городское поселение может включать несколько населённых пунктов...

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

Если хочешь более универсально, то лучше деревом. Я сделал без ограничений по колличество потомков, так наш архитектор, в по каждой улице дома проставил, и начал фамилии жильцов вписывать :) довольно удобно
...
Рейтинг: 0 / 0
23.10.2006, 17:43
    #34074894
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
Административное устройство согласно КЛАДР.
Декларирование возможных сочетаний на уровне DDL требует 8 сущностей.
Деревом его конечно, а ограничения на сочетания - в собственный словарь.
...
Рейтинг: 0 / 0
25.10.2006, 10:16
    #34079135
superbluesman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
Пару раз предлагал выложить для скачивания свою географическую базу (переработанный КЛАДР в древововидную структуру)
...
Рейтинг: 0 / 0
25.10.2006, 11:56
    #34079556
smoyk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
По моему в таком виде КЛАДР выложен на www.gnivc.ru, формат dbf иерархический метод классификации и последовательный метод кодирования внутри классификационной группировки. Лажа по моему. Хоть бы кто в реляционную БД его загнал (нормализованную естественно).
...
Рейтинг: 0 / 0
25.10.2006, 15:04
    #34080493
Кифирчик_
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
авторПо моему в таком виде КЛАДР выложен на www.gnivc.ru, формат dbf иерархический метод классификации и последовательный метод кодирования внутри классификационной группировки. Лажа по моему. Хоть бы кто в реляционную БД его загнал (нормализованную естественно).
Да, но его большой плюс, что он регулярно обновляется.
Может сделать примочку, которая автоматом бы его форматировала в нормализованное дерево (или искала изменения и переделывала) норм.дерево, которое можно в своих проектах использовать. Как думаете?
...
Рейтинг: 0 / 0
25.10.2006, 15:06
    #34080511
Кифирчик_
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
superbluesmanПару раз предлагал выложить для скачивания свою географическую базу (переработанный КЛАДР в древововидную структуру)
А как вы актуализацию базы поддерживаете? Поделитесь опытом
...
Рейтинг: 0 / 0
26.10.2006, 06:08
    #34082069
smoyk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
Ага я уже неделю сижу в этой помойке разюираюсь, пытаюсь по интербейзовским таблицам раскидать все по норамольному. НО... За то, что сделали со справочником похоже уже не поддается излечению. В том смысле, что в базу я его уже почти перевел, но из-за говенной структуры самого классификатора базу незя нормально нормализовать(прикольное выражение:))
...
Рейтинг: 0 / 0
26.10.2006, 06:16
    #34082073
smoyk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
Да, кстати, в описании деларирована структура "регионы-районы-города-населенные пункты". Можно ее смело смывать в сортир, структура у ModelR более правильная (но наскока она правильная? (или это чисто его базы структура, а не правительственной бд?)).
...
Рейтинг: 0 / 0
26.10.2006, 10:36
    #34082496
superbluesman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
TO Кифирчик_ :

1.
Признаться честно, один раз в 2003 году залил из КЛАДРа в свою древовидную структуру, с тех пор и юзают, к тому же ещё дозаливал данные об иностранных городах всего мира. В принципе юзера достаточно активно мой справочник юзают и ошибок не встречали, хотя конечно, их мельче чем города областного подчинения не интересуют. Проблемы (изменения), как я предположу - с деревнями, улицами. Тем не менее я сохранил оригинальные кладровские коды-поля. Так что обновить при желании можно.

2.
Написал T-SQL скрипт, который распарсивает КЛАДР и кладёт в мою древовидную базу + доп. вспом. таблицы.... Но потом грохнул этот скрипт за не надобностью



То smoyk:

Терпения, друг, терпения - всё там раскручивается в КЛАДРЕ нормально. по крайней мере им можно сказать спасибо, что в ИВЦ они там который год эту инфу со всех налоговых собирают и чистят. Конечно, с таблицей домов там лажа, но и поди собери такую информацию точно в нашей стране

К сожалению, счас свою базу не могу снова выложить (неоднократно коллеги по клавиатуре говорили спасибо когда высылал), поскольку счас работаю в большой конторе, где все порты закрыты. Вот сменю место - могу снова разместить для скачивания :)
...
Рейтинг: 0 / 0
26.10.2006, 17:59
    #34084814
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
smoykДа, кстати, в описании деларирована структура "регионы-районы-города-населенные пункты". Можно ее смело смывать в сортир, структура у ModelR более правильная (но наскока она правильная? (или это чисто его базы структура, а не правительственной бд?)).Это в точности то, что есть в КЛАДР (таблица KLADR), а x_KLADR это расширение, в меру моего понимания данных и документации МНС.
...
Рейтинг: 0 / 0
26.10.2006, 18:27
    #34084925
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
8 типов:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
select substr(
       case xk_4town_code when '000' then '' else '-4' end ||
       case xk_3city_code when '000' then '' else '-3' end ||
       case xk_2region_code when '000' then '' else '-2' end ||
       case xk_1rfsubject_code when '00' then 'e' else '-1' end, 
        2 ) entity_type      
from x_kladr
ENTITY_TYPE12-13-13-2-14-14-2-14-3-14-3-2-1
...
Рейтинг: 0 / 0
26.10.2006, 18:29
    #34084939
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
Сорри,
Код: plaintext
select distinct...
конечно
...
Рейтинг: 0 / 0
26.10.2006, 23:44
    #34085437
PWinter
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
coderinsideДобрый вечер! Подскажите как организовать структуру для хранения населенных пунктов. Страна - > Область -> Город - то вроде вопросов нет, но ведь кроме Области может быть еще и АО, край... а вместо города - > Район -> Поселок. Сами города, поселки не нужны, нужна именно структура чтобы ее потом сами заполняли.
Куда смотреть?
По контексту похоже, что речь о России.
Тогда смотреть сначала в Конституцию. В России всего три уровня иерархии:
Нулевой - Федерация
Первый - 89 субъектов Федерации, т.е. республика/край/область/Москва/Питер.
Второй - Район/нац.округ/город областного подчинения/(не помню как там делят Москву и Питер, админ.округ или где?)
Тогда и адресная структура до населенного пункта будет трехуровневой, причем населенный пункт может быть на любом: Москва и Питер на первом, города обл.значения на втором, все прочие на третьем.
Обратите внимание, что населенного пункта в почтовом адресе может и не быть. Пример из моей личной практики: Рязанская обл., Рязанский р-н, будка 183 км.
...
Рейтинг: 0 / 0
27.10.2006, 00:18
    #34085470
PWinter
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
Вот всегда так - сначала отвечу, потом весь топик дочитаю.
Чему бы я не советовал следовать в схеме КЛАДР (я критиковал еще ее предшественников на этапе разработки в 1995, мне не вняли, но я остался при своем мнении):
Нас.пункт в составе города областного подчинения 4-3-1 ничем не отличается от города районного подчинения 3-2-1, точно также, как 4-1 == 2-1, 4-2-1 == 3-2-1, и 4-1 == 2-1.
Нас.пункт в составе города районного подчинения вообще не нужен, его надо выносить ниже, т.е. туда, где улицы и переулки. "Нас.пункт в составе города" имеет смысл для крупных городов (Москва-Зеленоград, Питер-Зеленогорск), а для города районного подчинения это излишество.
Три уровня иерархии, три сущности. Населенный пункт может быть членом любого уровня.
Кстати, точно так, трехуровнево, устроена адресация населенных пунктов в США, Канаде, Австралии.
...
Рейтинг: 0 / 0
27.10.2006, 10:05
    #34085908
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
2 PWinter

Таковы реалии:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
select  k.name,
  Max ((select name from x_kladr_actual k2 where  k2.xk_code=k.xk_parent_code)) parent_name,
  sum((select count(*) from x_street s where  s.xk_code=k.xk_code)) n  
from x_kladr_actual k
where substr(
       case xk_4town_code when '000' then '' else '-4' end ||
       case xk_3city_code when '000' then '' else '-3' end ||
       case xk_2region_code when '000' then '' else '-2' end ||
       case xk_1rfsubject_code when '00' then 'e' else '-1' end, 
        2 ) ='4-3-2-1' 
       and xk_1rfsubject_code ='52'
       and  (select count(*) from x_street s where  s.xk_code=k.xk_code)> 10 
group by rollup  (k.name)
NAMEPARENT_NAMENБольшое ПикиноБор26НеклюдовоБор95ОктябрьскийБор30ТесоваяБор19Бор170
Кто ж будет переименовывать 170 улиц только в одном райцентре ради непонятных целей.
...
Рейтинг: 0 / 0
28.10.2006, 02:25
    #34088426
PWinter
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
Хороший пример, место знакомое. Ключевые слова - Ларис`98. :)
1. Непонятно, как Бор - город областного подчинения - попал на уровень ниже. Может быть тут собака и порылась?
2. Я никоим образом не предлагал переименовывать улицы в натуре. Вопрос был как разумно сохранить в бд существующее положение дел. Мое предложение сводилось к следующему: хранить населенные пункты в простой трехсущностной иерархии, а все нижеидущие компоненты адресов хранить в другой структуре, в той, где улицы, дома и пр. Надо ли эти компоненты структурировать или (как в америках) оставлять простой строкой - это совсем другой вопрос.
3. Даже если трех уровней недостаточно, можно ввести четвертый, но не городить ... (эпитет опущу), а добавить просто четвертую сущность, сохранив иерархию простой.
4. Как справедливо заметил Dik76, есть же еще ОКАТО (http://www.standard.ru/classif/okoatd/okoatd-17.phtml или еще лучше http://nalog.consultant.ru/doc46871.html), хорошо документированная классификация. Тоже, кстати, трехуровневая иерархия.
...
Рейтинг: 0 / 0
30.10.2006, 09:49
    #34090110
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
Из ОКАТО:
Признак второго уровня классификации - Р1 (разряд 3) имеет значение:
1 - автономный округ;
2 - район (в том числе внутригородской), округ;
4 - город, поселок городского типа.
Признак третьего уровня классификации - Р2 (разряд 6) имеет значение:
3 - внутригородской район, округ города;
5 - город, поселок городского типа;
8 - сельсовет.
Таким образом, кодовое обозначение, например, Даурского сельсовета Забайкальского района Читинской области - 76 212 825 - структурно состоит из следующих частей:
76 (1 и 2 разряды) - Читинская область;
2 (3 разряд) - признак района (второй уровень классификации);
12 (4 и 5 разряды) - код Забайкальского района;
8 (6 разряд) - признак сельсовета (третий уровень классификации);
25 (7 и 8 разряды) - код Даурского сельсовета.
Для сокращения общей длины кода при кодировании ряда объектов сделано отступление от описанной системы классификации и кодирования, а именно районы и города автономных округов, входящих в состав краев и областей, кодируются на втором уровне классификации (4, 5 разряды), а им подчиненные объекты (города, поселки городского типа и сельсоветы) кодируются на третьем уровне классификации (6, 7, 8 разряды). При этом признак Р2 (разряд 6) имеет следующие значения:
6 - город, поселок городского типа;
9 - сельсовет.
Например, кодовое обозначение Кункурского сельсовета Агинского района Агинского Бурятского автономного округа Читинской области - 76 122 912, где
76 (1 и 2 разряды) - Читинская область;
1 (3 разряд) - признак автономного округа,
а так как в Читинской области имеется только один подобный
объект (это имеет место в 5 из 7 краев и областей России, имеющих
в своем составе автономные округа), то уже само наличие признака
"1" идентифицирует Агинский Бурятский автономный округ. Поэтому в
разрядах 4 и 5 можно закодировать как автономный округ в целом
(признак "1" в сочетании с нулевыми значениями 4 и 5 разрядов),
так и объекты окружного подчинения. В данном случае 22 означает
Агинский район. Значение "9" в 6 разряде - признак сельсовета,
последние 2 знака (12) обозначают Кункурский сельсовет.
Если в состав края или области входят два автономных округа (второй уровень классификации), то административно подчиненные им объекты кодируются на втором уровне с использованием серий кодов. Например, в состав Красноярского края входят Таймырский (Долгано-Ненецкий) автономный округ и Эвенкийский автономный округ. Таймырский (Долгано-Ненецкий) автономный округ имеет код 04 100. Административно подчиненные ему объекты кодируются серией кодов (на втором уровне классификации) 110 - 129. Эвенкийский автономный округ имеет код - 04 130, подчиненные ему объекты кодируются серией кодов 140 - 149.

И т.д. Куча исключений (действительно документированных) в угоду компактности кода. К тому же, цели у них разные. Например, в ОКАТО нет улиц, но есть районы городов, в КЛАДР районов городов нет, ибо адрес не включает районы. ИМХО КЛАДР для адресов удобней.
...
Рейтинг: 0 / 0
31.10.2006, 06:51
    #34092779
johndes
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
Да посути кладр хорошо подходит для таких точных баз (особенно актуальностью по сравнению с другими вариантами)...
если на уровне приложения посидеть и составить грамотно запросы, то можно из него выводить хоть как, хоть все города области или края, или все улицы города, и прилежащих посёлков, + можно выводить иерархический путь до населённого пункта и т.д. главно включить мозги в нужном направлении...
С одной проблемой я не справился - у меня выводится так - Хабаровск (г), а надо так - г. Хабаровск... решение перенести socrname вначало и поставить точку не подходит - получица например Респубика. Калмыкия...
Есть варианты?
...
Рейтинг: 0 / 0
31.10.2006, 15:18
    #34094583
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Структура БД для хранения населенных пунктов
Например
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT s.*,
     scname || CASE when Upper( SCNAME ) <> Upper(SOCRNAME) AND
               NOT (scname LIKE '%-%' 
                    OR scname LIKE '%/%' 
                    OR Upper( SCNAME )=scname
                    OR  InStr(REVERSE(socrname),' ')> 0  and scname LIKE '%'||SubStr (socrname, Length(socrname)- InStr(REVERSE(socrname),' ')+ 2 ))
          THEN '.'
          ELSE ' '
     end    ScnamePlus
FROM  SOCRBASE  s
А то просто вбейте признак в SOCRBASE . Она ж короткая.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура БД для хранения населенных пунктов / 25 сообщений из 29, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]