База банковских счетов

Я создаю базу данных для «банка» и просто не уверен, был ли мой метод привязки счетов к клиентам наиболее эффективным. Вот несколько корпоративных правил:

-есть 2 вида счета (текущий и сберегательный)

-каждая учетная запись имеет поле для: баланс, дата последнего доступа

-текущие счета имеют овердрафт

-сберегательные счета имеют процентную_ставку

- клиент может иметь столько счетов, сколько он хочет

- учетная запись может быть «подписана» на неограниченное количество людей

Я просто не уверен, что лучший способ - просто установить процентную ставку и овердрафт в таблице счетов равными нулю, если это неправильный тип счета.

Извините, если этот вопрос поставлен не очень хорошо (здесь я нарушаю свою девственность stackoverflow). Кроме того, вот ссылка на созданную диаграмму ER: https://drive.google.com/file/d/0BwKmjTsIbwP0SE9Xbk1ycnkyV0E/edit?usp=sharing

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

Заранее спасибо!


database database-design account entity-relationship bank
person user3665815    schedule 22.05.2014    source источник
comment
Это больше вопрос дизайна, чем вопрос программирования.   -  person Hans Then    schedule 22.05.2014

Ответы (1)


arrow_upward
16
arrow_downward

Вы берете предоставленную вам информацию и нормализуете данные в отношения. Вот почему вы используете реляционную базу данных.

Итак, начнем с клиентов. Мы создадим таблицу Customer. Как правило, имена таблиц в единственном числе.

Customer
--------
Customer ID
Customer name
Customer address
...

Как видите, все данные в таблице Customer относятся к клиенту.

Далее мы создадим таблицу Account.

Account
-------
Account ID
Account Type ID
Account balance
Account interest rate
Account overdraft
Account last access time stamp

Все данные в таблице Account взяты из вашего заявления о требованиях. Процентная ставка устанавливается равной нулю для беспроцентных счетов. Овердрафт устанавливается равным нулю для счетов без овердрафта.

Далее мы создадим таблицу типов счетов.

Account Type
------------
Account Type ID
Account Type

Данные будут (0, проверка) и (1, экономия). С помощью таблицы типов счетов вы можете легко добавлять новые типы счетов, например (2, Депозитный сертификат).

Далее, даже если вы не упомянули об этом, мы создадим таблицу транзакций. Это необходимо для печати ежемесячных отчетов.

Transaction
-----------
Transaction ID
Transaction time stamp
Transaction amount
Account ID

Хорошо, мы настроили все таблицы типов сущностей для банковского дела. Теперь давайте настроим таблицы отношений.

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

Итак, давайте создадим таблицу Customer Account.

Customer Account
----------------
Customer ID
Account ID
Customer Account creation time stamp

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

Я считаю, что мы закончили создавать таблицы.

  • Учетная запись имеет тип учетной записи.

  • У клиента может быть много счетов.

  • У аккаунта может быть много клиентов.

  • Учетная запись может иметь много транзакций.

  • Транзакция проводится на один счет.

person Gilbert Le Blanc    schedule 22.05.2014
comment
В таблице транзакций должны быть ссылки на обе стороны, участвующие в транзакции. У вас есть только один. - person HIRA THAKUR; 19.02.2018
comment
Как это можно масштабировать, если для нового типа учетной записи требуются специальные поля, которые являются эксклюзивными для этого нового типа учетной записи? Не лучше ли иметь разные таблицы для разных типов счетов? или используйте объединенную таблицу с родительской таблицей, содержащей общие поля. Я изо всех сил пытаюсь разработать такое решение и думаю о возможных решениях, которые будут хорошо масштабироваться. Ваше решение уже является хорошим решением. - person bluelurker; 28.06.2021