B Ortet

Ok, i can see it. It makes sense...
But in a case of a customer that as multiple CheckingAccount, and multiple SavingAccount. What kind of relationship the accounts would have? Because the SavingAccount doesnt exist without a CheckingAccount...
Example:
Customer A has a CheckingAccount = {2, 3}
And the SavingAccount id = 21, its associated with the CheckingAccount = 2
And the SavingAccount id = 31 its associated with the CheckingAccount = 3;

Could it be:

public class SavingAccount{      private int id;      private CheckingAccount checkingAccount; }
Where the checking account its a reference of the CheckingAccount in the list of the BankAccount in the Customer class??
public class Customer{      private List<BankAccount> bankAccounts; }

Well I belive I was wrong. The original ideia for this post was in the fact that i wanted to Link the table Customer with the CheckingAccount, which would resulted in a third table, Customer_CheckingAccount.
And the table CheckingAccount have a relationship of one to many with the TermAccount.
The problem appear when I tought that were possible to Link a Customer to the TermAccount without linking to the CheckingAccount.  Apparently it's not how it works in the banking world.
But it was a mistake of my part. It was a design problem of the database

A customer cant have any type of account unless he has a checking account. He can have multiple checkingAccount.
But all those other types of accounts will depend on the CheckingAccount. So a customer can not have a SavingAccount without a CheckingAccount.
In the case of the relationship that a Customer has various accounts... how could it be structured?
Lets say a Customer class its like this, and perhaps it has more information detail about the customer

public class Customer{
 private int customerID;
 private String customerFirstName;
 private String customerLastName;
 private CustomerAccount customerAccount;
}

Is this a bad pratice?

int valor = daoContaBancaria.getNumeroMaximoContaAPrazo(numeroContaCorrente);

This will query for a specific CheckingAccount, and will return the number of the last associated account related CheckingAccount number.
Unless the same account owner is trying to open an account in 2 diferent places, there should be no problem, i guess...

For instance: An CheckingAccount number 2. When the owner wants to create a SavingAccount related to that account number 2, before inserting the entry in the database,
the method will query to see the max value of all the accounst associated with 2, and return the value.
If and CheckingAccountNumerber = 3, wants to do the same in the same time,  the method will query for the accountNumber = 3, them return the value related to the accountNumber 3.

A CheckingAccount has-zero-or-more BankAccount(s)
FALSE therefore not aggregation

Its actually true. But a CheckingAccount doesnt have one or more CheckingAccount.
But it has the SavingAccount the CertificateDepositAccount, and the other types of account the extends the BankAccount except the CheckingAccount.

Yes, other users will acess the database, using and interface. When creating a new object, a method will query the database to get the last account number entered and increment uppon that to create the new object, ande then insert it to the database...
Only now I've seen the I posted the code in portuguese...

Im sorry, i probably expressed in the wrong way.
What im trying to understand is if makes sense to store the list of bankAccounts types that are associated with the checkingAccount, inside the CheckingAccount class.
In the relational database, the way i know the the various types of bankAccount is related with the checkingAccount is by creating a foreign Key of the checkingAccount inside those tables...

It is the same as the example i put in the previous post, no new datatype.

public abstract class BankAccount{ } public class CheckingAccount extends BankAccount{ } public class CertificateDeposit extends BankAccount{ }

:-)
The CheckingAccount that have the CertificateDeposits. He could have or not... Depending on the cliente.
The CheckingAccount, can have various types of baking accounts associated to it.

For example, a user has a UserAccount. and he can do some operations with that userAccount. Each time he log in, there will be created a Session, with the date and time of the login.
Its correct to have those Sessions Stored in the UserAccount class?

Its associated to he checking account. A user can only have a certificate deposits if he as a Checking account.

I have same doubt when aplied to a Session of a UserAccount.
Everytime a user login, results of a Session, so i belive the UserAccount should store all the Session inside the class in a List.
Please correct me if im thinking the wrong way...

Guys what you think its the best solution for this scenario, where i have these three tables. I want to relate the tbl_client with the tbl_checkingAccount and tbl_SavingAccount.
If I have one table to related them, the foreign key of the agregated table would come from two diferent tables. What way i found was to have two tables, agregating the tblClient - tblCheckingAccount, and another one tblClient - tblSavingAccount.
The problem is, those tables have the same attributes, the only diferente is where the foreign key comes from.
tlb_client( nic varchar(30) unique not null )

tbl_checkinAccount( accountNumber int auto_increment not null )

tbl_savingAccount( accountNumber int auto_increment not null checkingAccountNumber int not null foreign key (checkingAccountNumber) references tbl_checkingAccount (accountNumber) )

Guys I have another doubt, regarding de OOP design. As for example the class in the previous post. Its a bad design to have, the list of CertificateDeposit inside the CheckingAccount?
In the relational database, the CertificateDeposit table, have as a foreign key the "AccountNumber" of the CheckingAccount.
public abstract class BankAccount{  private int accountNumber;  private LocalDate openDate;  private float balance; public abstract boolean withdraw(float value); public class CheckingAccount extends BankAccount{   private List<CertificateDeposit> listCertificateDeposit = new ArrayList<>();   public boolean withdraw(float value){     if(value >= limit)        return false; } } public class CertificateDeposit extends BankAccount{ }

Could you recomend me a good book, or any resource about de Object Oriented design, with exercises?

Hey guys, I managed to make it work with java code.
When im going to insert a new row in a database, i query for the last item and add the numbers
int valor = daoContaBancaria.getNumeroMaximoContaAPrazo(numeroContaCorrente); if(valor == 0) numeroContaMax = numeroContaCorrente * 1000  + 1; else { numeroContaMax = valor + 1; } contaAPrazo.setNumeroConta(numeroContaMax);

the full stop was just to separate the numbers visually.
But i think is not possible.

Only if i control the idSavingAccount in he application layer, with a static member in the class SavingAccount

Campbell Ritchie wrote:Yes,, but I can see a problem. You are risking a collision of keys every 1001 new accounts (or worse).

where?
the idCurrentAccount will never repeat. Each of the new CurrentAccount will have a diferent value.
Imagine the idCurrentAccount = 1
All the dependent account will be:
1.001
1.002
1.003
...
1.999
1.1001
1.1002
(...)
2.001
2.002
2.003
...
2.999
2.1001

For example:

CurrentAccount(
idCurrentAccount int primary key auto_increment;
);

SavingAccount(
idSavinAccount int primary key auto_increment,
idCurrentAccount int not null,
foreign key (idCurrentAccount)
references CurrentAccount(id)
);

What i trying to see is if I can make that, when a new entry in the SavingAccount, the primaryKey of the SavingAccount could be:
idCurrentAccount = 1
idSavingAccount = idCurrentAccount + auto_increment.
idSavinAccount = 1001

And when a idCurrentAccount = 2, register a SavingAccount, it would have the primary Key 2001.
And if he register another SavingAccount it would have the idSavingAccount = 2002.

Does it make sense??