База "Арендодатель"

Необходимо решить следующую задачу.

Имеется арендодатель ("Хозяин") и ряд объектов, которые он сдает в аренду арендаторам ("Съемщик"). Каждый месяц съемщику необходимо осуществлять следующие платежи:
1. Арендная плата
2. Плата за электроэнергию
3. Плата за энергоресурсы
4. Плата за коммунальные услуги
5. ….
Список счетов и их наименование может изменяться в зависимости от ЖЭКа.
Размеры платежей по пп 2-… не зависят ни от Хозяина ни от Съемщика. Размер платежей по п.1 определяет Хозяин по договоренности со Съемщиком.

Каждый месяц поступают следующие данные:
1.Размеры платежей, обязательных к уплате по пп 2-… за прошлый месяц.
2. Фактические размеры оплат по каждому из счетов по каждому Съемщику .
3. Размер оплаты по п.1 на следующий месяц либо на несколько месяцев вперед

Предназначение базы данных - контроль над оплатой/задолженностью Съемщиков перед Хозяином.

Система должна обеспечивать следующие возможности:
1. Ввод любых "Счетов"
2. Группировать счета в произвольном виде (к примеру счета 2-4 собрать в группу "Комуналка" и выдавать данные по этому "обобщенному счету"

Система должна обеспечивать следующие функции:

Отслеживать задолженности Съемщиков перед Хозяином по каждому из счетов.
Выдавать информацию о задолженности/превышении в разрезе Съемщика/счета по превышениям/задолженностям и о суммарном размере задолженности/"переплаты".
Рассчитывать чистый доход хозяина на определенный период вперед на основании прогноза проплат.
Вопрос : какие под это дело возможны варианты структуры.

Свой вариант я приведу чуть позже.

akuz, задачка то учебная, простая, для отработки подходов...

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

Jinn,
Мыслить глобально, конечно, очень хорошо, вот только и локальные задачи тоже кто-то должен решать.
В описании задачи нигде не сказано, что что система должна быть предназначена для "комплексной системы коммунального хозяйства". Просто есть Хозяин, несколько съемщиков и несколько ЖЭКов. Хозяину надо знать состояние взаиморасчетов...
А пока я приведу свой вариант (из 3-х таблиц)

Большое спасибо, akuz и Jinn за интерес к данной теме и содержательные ответы, только вот смущает меня, что, по-моему, Ваш опыт Вам немного мешает отвечать на вопрос. Может я и не совсем грамотно изложил т.н. "техзадание", дело не в этом. Я хотел получить ответ в рамках поставленной задачи, либо критику постановки задачи, либо критику моего варианта. Вместо этого уважаемый akuz на основе своего опыта и моего "техзадания", по всей видимости, составил свое собственное представление о том, что представляет из себя задача и привел решение этой своей задачи. При этом введено много новых терминов, отсутствовавших в "техзадании", к примеру "Адрес", "телефоны","физическое лицо","ИНН", "Паспортные данные" "Договор","дата подписания", "номер", "агенство"," Дата начала действия","Предыдущий договор " и т.п.
Целью моего вопроса было:
1. Смоделировать несложную, но в то же время емкую "учетную проблему"
2. Обсудить варианты структур данных под поставленную мною задачу.
Целью моего вопроса не являлось:
1. Создать комплексную модель данных по данному вопросу с учетом всех возможных объектов,атрибутов и.т.п
Призываю всех быть более внимательными и стараться отвечать на Заданные вопросы, либо указывать на то, что вопрос задан неграмотно.

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

1. Господа, прошу не ругаться, соблюдать "политкорректность"
2. Привожу еще раз свой вариант структуры в русскоязычном варианте:

Если заполнить эту структуру тестовыми данными из варианта Cat2 то получится следующее:

Основное, что меня смущает во всем этом вопросе, заключается в следующем - получается, что решить данную задачу можно двояко - либо кривая структура для хранения данных, но зато простые запросы, либо красивая структура, но сложные запросы (у меня, к примеру, не получается сделать "Оборотку" по таблице Долги и платежи без подзапросов). Нет ли тут какой крутой философии? По-моему выходит, что Реляционные БД вообще не подходят для решения учетных проблем, поскольку даже такая простая задача "Про Карабаса-Барабаса", как выясняется, не имеет простого, красивого и однозначного решения