Здравствуйте.

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

Для начала рассмотрим понятие Банк более детально
1. Физическое устройство банка (персонал, услуги, подразделения).
2. Клиенты (физ. лица, юр. лица).
3. Внутренние операции (счета, пополнение/вывод, перерасчет(кредит,или накопительный счет), поручения, архив, статистика).
4. Внешняя политика банка (инвестиции, займы).

Возможно имело бы смысл раскидать п. 3 по п. 1 и 2.,все-такие физ. лица и юридические лица совершают разные операции, но мне так кажется, что логически там большой разницы нету.

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

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

П-ЛПопробуйте выбрать только один пункт/направление автоматизации и проработать его хоть насколько-то добросовестно.
В принципе так и планирую поступить с п. 3

Вот так я разрисовал п. 1

# Employees
Эта часть у меня будет скорее для красоты и для количества таблиц и понимания того,что я полностью описал предметную область



# Accounts, Services
Услуги банка. Тут мне чего-то в голову не приходит, кроме типов Аккаунтов. Если текущий то %-ная ставка 0, а если кредитный или накопительный, то будет отличаться знак. Возможно стоит еще создать таблицу документов, требуемых для открытия того или иного счета

На всякий случай поясню цель этого проекта. Их 3
1. Спроектировать относительно большую БД (для непрофессиоанала) с кучей таблиц и зависимостями. Тут моя задача это попытаться разобрать по косточкам некую сложную предметную область. Разумеется с приближениями и упрощениями, т. к. я выбрал уж больно сложную тему.
2-3. Это уже относится к Java - Освоить пару фреймворков, сделать эмулятор/рандомизатор событий пришел/ушел клиент, открыл/закрыл счет, создал поручение (единоразовое/регулярное), перерасход средств, банкротство компаний, контроль за достаточностью капитала и т. д. В соответствии с этим, постоянный перерасчет состояний счетов.

П-ЛВаша попытка кадрового учета очень слабая. Есть отстоявшийся минимальный набор таблиц для штатного расписания, назначений, переводов и увольнений.

Ну париться на счет принятий на работу/увольнений, расписаний, болезней, отпусков и т. д. я не буду. Есть какая-то грань, которую я должен провести, чтобы не потонуть.
Ну и в конце концов мне никто не мешает потом систему апгрейднуть в соответствии с принципами SCRUM

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

П-Л Прочитайте нормативно-обязательный план счетов банка.

А где это можно прочитать ?

П-ЛавторНу париться на счет принятий на работу/увольнений, расписаний, болезней, отпусков и т. д. я не буду. Есть какая-то грань, которую я должен провести, чтобы не потонуть.
Я же говорю - вы замахнулись на масштаб, из которого вам придется выкинуть слишком много, т.е. то, что составляет суть задачи. Кадры:
перечень физлиц
справочник должностей
структура организации по подразделениям
штатное расписание в разрезе структуры и должностей
приказы о назначении/переводе/увольнении физлиц в/из слоты штатного расписания

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

За скобками оставлены отпуска/больничные, табель, зарплаты, налоги на з/п ...

Справочник должностей есть. До физ. лиц-клиентов еще не дошел. Всякие там подразделения, расписания и движения кадров мне не нужны, ТЗ этого не подразумевает.

Arm79GeronemoДо физ. лиц-клиентов еще не дошел
Как бы еще и ЮЛ есть :-) И ИП.

Вы 1-е сообщение темы читали ?

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

ШайтанGeronemoНа всякий случай поясню цель этого проекта. Их 3
1. Спроектировать относительно большую БД (для непрофессиоанала) с кучей таблиц и зависимостями. Тут моя задача это попытаться разобрать по косточкам некую сложную предметную область. Разумеется с приближениями и упрощениями, т. к. я выбрал уж больно сложную тему.
2-3. Это уже относится к Java - Освоить пару фреймворков, сделать эмулятор/рандомизатор событий пришел/ушел клиент, открыл/закрыл счет, создал поручение (единоразовое/регулярное), перерасход средств, банкротство компаний, контроль за достаточностью капитала и т. д. В соответствии с этим, постоянный перерасчет состояний счетов.
Может бать такой вариант стоит рассмотреть:

Если на Java отнесено 2 цели (№2 и №3), то с Java и начинай.
Создавай сервер приложения
а БД "упакуй" в EAV

Если начнёт взлетать - тогда и допилишь (нормализуешь) БД

А так получается задача очень широкая, и времени потребует много

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

Мне нужна некая приближенная модель + логика обработки данных. Я там расписал Понятие сотрудник на 6 таблиц. Я вообще мог обойтись 1-й таблицей - ФИО, логин и пароль. Все. Этого приближения уже вполне достаточно было бы. Но я сделал целых 6 таблиц, а мне тут советуют всякие подразделения, расписание, приказы о переводе/повышении и т. д.

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

Суть проекта и требования к нему следующие.
1. Это должен быть достаточно большой с т. з. количества сущностей проект. Я не проектировщик БД, это не моя прямая специальность. Но хотелось бы иметь в активе тот факт, что я на довольно сложной предметной области смог вычленить самое главное и при этом структура все равно оставалась бы близкой к реальности, довольно сложной и большой для непрофессионала и некоммерческого продукта (таблиц 30, например).
2. БОльшая часть проекта, это не БД, а Java, бизнес-логика. На самом деле я нечто подобное написал в 1-м сообщении
GeronemoВ целях саморазвития хочу сделать проект, симулирующий работу банка. Для начала надо определить структуру БД. Понимаю, что предметная область очень большая, поэтому будут некоторые упрощения.
Как видите, структура БД для меня это только начало проекта и если я создал тему здесь, а не в подфоруме java, это только потому что я для начала хочу понять от чего мне отталкиваться, от каких данных. Мне не нужна детализация, по которой были бы подразделения, отделения (время их работы и пр. атрибуты), банкоматы, штатные расписания, потому что я этими данными нигде оперировать не буду. Они будут статичны, либо таблицы будут пустыми. Что я вобью вручную, то и будет. А логически, если человек берет кредит, то разницы большой нету, в каком именно отделении он это делает. Только, если ради ведения статистики (в целях повышения эффективности). Но опять же, это очень сильно усложняет задачу. Возможно я к этому вернусь позже, на итерации номер 3 (я тут писал чуть выше про SCRUM).
3. Для меня важно было, чтобы в рамках проекта я оперировал бы каким-то одним ресурсом (в этом случае - деньги), чтобы сделать систему максимально нагруженной и при этом суметь справиться со всякими коллизиями (вопросы синхронизации потоков, защиты данных и т. д.). Вот почему это именно банк. У меня есть пара проектов значительно более простых и там такого рода задачи решаются очень просто. Для меня этого мало.
4. По поводу глубины детализации. Возможно все же стоит какую-то часть предметной области изучить досконально. И, в принципе, Персонал для этого вполне подходит, т. к. таблицы будут все равно пусты и если что-то не так, то помешать бизнес-логике приложения это не сможет.

Кстати, у меня возник наиинтереснейший вопрос - с какого счета банк платит зарплату, аренду и пр. расходы. У банка есть свой собственный счет в своем банке ?

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

Продолжение п. 1

# The internal structure of the bank

# List of All possible Accounts (current, credit, etc...)
CREATE TABLE AccountTypes(Id bigint AUTO_INCREMENT, AccountTypeName varchar(50) NOT NULL, basePercentage decimal NOT NULL, currency int NOT NULL, PRIMARY KEY(Id));

# List of All possible Services (comissions for transfers, payments for sms-informer, etc...)
CREATE TABLE ServicesTypes(Id bigint AUTO_INCREMENT, ServicesTypeName varchar(50) NOT NULL, basePercentage decimal NOT NULL, minimalCost decimal, PRIMARY KEY(Id));

# Maybe Load this Info from XML ?
CREATE TABLE TaxesTypes(Id bigint AUTO_INCREMENT, TaxesTypeName varchar(50) NOT NULL, basePercentage decimal NOT NULL, PRIMARY KEY(Id));

# Costs: rent, depreciation..... wages fund, social fund
CREATE TABLE CostsReport(Id bigint AUTO_INCREMENT, Month int NOT NULL, Year int NOT NULL, FixedCosts decimal NOT NULL, VariableCosts decimal NOT NULL, PRIMARY KEY(Id));

# Payments: percents for saving account, payments when client close account, percents for external loans, investment payments
CREATE TABLE PaymentsReport(Id bigint AUTO_INCREMENT, Month int NOT NULL, Year int NOT NULL, TotalPayments decimal NOT NULL, PRIMARY KEY(Id));

# Income: percents for credits, comissions, investment revenue
CREATE TABLE IncomeReport(Id bigint AUTO_INCREMENT, Month int NOT NULL, Year int NOT NULL, TotalIncome decimal NOT NULL, PRIMARY KEY(Id));

Что-то типа такого для начала.

1xenix, можно посмотреть модели здесь

Спасибо за ссылку. Такое ощущение, что моя модель будет даже посложнее, чем у них.

Тут возникла небольшая проблема. Я хочу завести такую сущность, как Аккаунт. А именно - некий банковский счет. Я не хочу плодить разных типы аккаунтов (возможно я не прав ?), просто одним из столбцов будет тип аккаунта и их будет штук 10.
При этом аккаунт может быть заведен для физ. лица, а может быть для юридического.
Таблицы Физ. лиц и юридических у меня разные. А тут в таблице аккаунтов все они будут вперемешку.
Проблема вот в чем. Мне нужно из таблицы Аккаунт сделать поле Owner - FOREIGN KEY в 2 разные таблицы, чтобы это работало так - если это счет юр. лица, то ищем владельца счета в таблице юр. лиц, а если физ. лицо, то ищем в таблице юр. лиц.

Самое простое решение - это сделать тупо 2 таблицы - AccountsForPersons и AccountsForCompanies. Но тогда при разработке бизнес-логики увеличивается количество кода. Логически нам нету разницы, дали мы кредит в 100000$ мужику или компании. Поэтому мне хотелось бы оставить 1 таблицу. Но как тогда быть с FOREIGN KEY

Arm79у ФЛ и ЮЛ общая таблица-предок
Спс.

Как Вам такое

gandjustasGeronemo,

А ты какую проблему решить хочешь? Бд в вакууме не бывает, надо понять прикладную логику.

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

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