Проектирование БД. Учет ретроспективы.

← →
Ольга (2005-07-20 09:20) [0]

Представлю (очень упрощенно) структуру проектируемой базы. Хотелось бы услышать конструктивную критику и предложения.
Сущности:
счетчики, квартиры, владельцы квартир.

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

Таблицы-классификаторы:
Владельцы Квартиры Счетчики
ID_vl ID_kv ID_sch
<набор атрибутов> <набор атрибутов> <набор атрибутов>

Таблицы связей:
Влад-Кварт Кварт-Счет
Date_begin Date_begin
Date_end Date_end
ID_vl ID_kv
ID_kv ID_sch

Таблица данных:
Показания счетчиков
ID_sch
Кв.ч

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

← →
Fay © (2005-07-20 09:22) [1]

2 Ольга (20.07.05 9:20)
А нельзя ли описать стуктуру на DDL ?
Я (думаю, не только я) нифига не понимаю тот способ описания, который ты выбрала.

← →
Ольга (2005-07-20 09:32) [2]

> А нельзя ли описать стуктуру на DDL?

Я может совсем дремучая, т.к. не знаю что есть DDL (или не воспринимаю аббревиатуру). Поясните, пожалуйста.

← →
stone © (2005-07-20 09:38) [3]

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

Чтобы периоды не пересекались убери Date_end. В результате начало нового периода будет одновременно концом предыдущего.

> Таблица данных:
> Показания счетчиков
> ID_sch
> Кв.ч

Добавь дату, на момент которой существуют эти показания

← →
evvcom © (2005-07-20 09:45) [4]

> DDL

Data Definition Language, пример: CREATE TABLE.

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

← →
Goffman © (2005-07-20 09:54) [5]

> В результате начало нового периода будет одновременно концом
> предыдущего.

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

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

А если решит поставить новый счетчик?

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

← →
stone © (2005-07-20 09:55) [6]

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

Не получится, счетчики еще могут ломаться, заменяться и т.д. Так что "долой" не получится.

← →
stone © (2005-07-20 09:57) [7]

> Goffman © (20.07.05 09:54) [5]
>
> > В результате начало нового периода будет одновременно
> концом
> > предыдущего.
>
> Не получиться. А если единственный хозяин квартиры, не дай
> бог, умрет.

И что, нового владельца квартиры уже не будет никогда?

← →
evvcom © (2005-07-20 10:02) [8]

> А если решит поставить новый счетчик?
...
> Не получится, счетчики еще могут ломаться, заменяться и
> т.д.

И что? Добавляешь новый счетчик в справочник, привязываешь его к квартире и используешь уже его. Какие проблемы?

> > В результате начало нового периода будет одновременно
> концом
> > предыдущего.
>
> Не получиться. А если единственный хозяин квартиры, не дай
> бог, умрет.

И опять и что? Ведь мрут же. Каким образом это влияет на начало "нового" периода?

← →
stone © (2005-07-20 10:04) [9]

> И что? Добавляешь новый счетчик в справочник, привязываешь
> его к квартире и используешь уже его. Какие проблемы?

История теряется, уже не проследишь какие счетчики стояли до этого, а значит и не посчитаешь сколько потратили электричества, на какую сумму и т.д.

← →
evvcom © (2005-07-20 10:05) [10]

> История теряется, уже не проследишь какие счетчики стояли
> до этого

А кто сказал, что старый счетчик из справочника надо удалять?

← →
Goffman © (2005-07-20 10:09) [11]

> И опять и что? Ведь мрут же. Каким образом это влияет на
> начало "нового" периода?

А кто же будет открывать новый период, если, вдруг, открывать будет некому

← →
stone © (2005-07-20 10:10) [12]

> evvcom © (20.07.05 10:05) [10]

Ладно, попробую на пальцах:
с 1/01/2001 стоял счетчик с ID=1
с 1/01/2004 поставили счетчик с ID=2
как в твоей схеме после 1/01/2004 определить какой счетчик стоял до этого (для последующих операций), елси не вести историю "Кварт-Счет"?

← →
MOA © (2005-07-20 10:11) [13]

2Ольга
Работаю как раз в небольшой энергосбытовой компании. Такую программулю ваяю потихоньку с 97-го года ;).
По сабжу:
1. Забыты трансформаторы тока
2. В связи "владельцы-квартиры" я убрал поле Date_end - у квартиры не может не быть владельца. Зато в атрибутах самой квартиры это поле есть (сгорела, разрушена при землетрясении, и т.д.)
3. СтОит ввести жильцов (у меня сразу их не было - в связи с монетизацие льгот за..ся)
4. В показаниях ещё поле - контрольные/нет
5. Счётчики бывают многотарифные, причём, их активно ставят
6. Спросите, как у вас разруливают коммуналки
Если интересно - можно поговорить далее ;).

← →
stone © (2005-07-20 10:12) [14]

> Goffman © (20.07.05 10:09) [11]
> А кто же будет открывать новый период, если, вдруг, открывать
> будет некому

Дом снесут? Или наследники откажутся от квартиры?

← →
MOA © (2005-07-20 10:18) [15]

Да, ещё. Забыты таблицы для учёта, когда счётчика нет совсем (украли, сломали ;). Варианты - по средней мощности в зависимости от периода (зимой - больше и т.д.), по утверждённым месячным нормам на жильца (вот тут я лажанулся - не было их рагьше), конторолёр тупо говорит киловаттчасы в месяц.
Удачи!

> Дом снесут? Или наследники откажутся от квартиры?

Всякое бывает. Их может вообще не быть.
Хотя, если в таком случае владельцем автоматически становиться государство, то соглашусь с Вами

> Ладно, попробую на пальцах:
> с 1/01/2001 стоял счетчик с ID=1
> с 1/01/2004 поставили счетчик с ID=2
> как в твоей схеме после 1/01/2004 определить какой счетчик
> стоял до этого (для последующих операций), елси не вести
> историю "Кварт-Счет"?

Попробую и я на пальцах.
Счетчики
ID_sch ID_kv Date
1 1 1/01/2001
2 1 1/01/2004
Т.е. таблицы "Счетчики" и "Кварт-Счет" объединяются, удаляя только зависимость многие ко многим, оставляя "одна квартира - много счетчиков" и все остальные нужные параметры. Запросы заметно упростятся. Еще вопросы?

> Попробую и я на пальцах.
> Счетчики
> ID_sch ID_kv Date
> 1 1 1/01/2001

Я бы не стал путать сущности. Они должны быть независимы. Счетчики - самостоятельная сущность, они имеют кучу атрибутов, и никак на этом уровне не могут быть сопоставлены с конкретной квартирой.

Опять же возвращаясь к твоей схеме. 1-ый счетчик с 1/03/2004 поставили в другую квартиру. Проследи историю.

← →
Ольга (2005-07-20 10:43) [20]

[1]
Я так поняла, что стуктуру на DDL уже приводить не надо - разобрались. Можно, конечно, но база у меня пока на бумаге.
[3]
На счет конца периода - я думаю его надо оставить, чтобы явно фиксировать событие (поломку счетчика, снос дома..., о печальном не будем), а не искать начало следующего, которого можно и не найти.
Дату в табл "Показания счетчиков" я, конечно, пропустила.

Пересечения периодов в одной таблице связей быть не может - это будет отслеживаться при вводе. Я имела в виду пересечение периодов из разных таблиц связи. Одним запросом будет проблематично считать данные по нескольким сущностям.

[4]
Владелец имеет полное право забрать свой счетчик в новую квартиру. Счетчик привязан к квартире, а не к владельцу, добавляем новую запись в таблицу связи: новый период - новая квартира - старый счетчик. Я здесь не вижу подвоха.

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

Я так поняла, что я на правильном пути и принципиально другого подхода нет?

> Я так поняла, что я на правильном пути и принципиально другого
> подхода нет?

Аминь. Да пребудет с тобой Сила.

> Опять же возвращаясь к твоей схеме. 1-ый счетчик с 1/03/2004
> поставили в другую квартиру.

см. [4]
Я предложил. Если же не путать сущности и перенос счетчика явление нередкое, то, конечно же...

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

Это другое дело. Кроме выработки турбогенератора есть еще много чего другого, где используются счетчики. И на электростанции замена счетчика, ремонт и установка в другое место - обычное дело. Мне это знакомо не понаслышке. :)

Проектирование БД. Учет ретроспективы. Найти похожие ветки