Je sais que cette question est très ancienne, mais comme elle n'a pas encore de réponse acceptée, j'ai quelques idées.
Une possibilité consiste à utiliser les fonctionnalités ORDBMS - en d'autres termes, utiliser l'héritage de table. Dans PostgreSQL vous pouvez le modeler comme ceci:
(Voir la documentation sur l'héritage PostgresSQL http://www.postgresql.org/docs/9.3/static/ddl-inherit.html)
CREATE TABLE account
(
account_id INT,
PRIMARY KEY(account_id)
);
CREATE TABLE corporate_customer
(
company_name VARCHAR(32),
country_code CHAR(2),
PRIMARY KEY(company_name)
) INHERITS(account);
CREATE TABLE private_corp_customer
(
private_comp_id INT,
company_owner VARCHAR(32),
PRIMARY KEY(private_comp_int)
) INHERITS(corporate_customer);
CREATE TABLE public_corp_customer
(
stock_ticker VARCHAR(6),
PRIMARY KEY(stock_ticker)
) INHERITS(corporate_customer);
CREATE TABLE government_customer
(
dept_nbr INT,
country CHAR(2),
PRIMARY KEY(dept_nbr)
) INHERITS(account);
Différents fournisseurs de SGBD mettront en œuvre ce de différentes manières. En PostgresSQL, il y a quelques mises en garde décrites ici:
http://ledgersmbdev.blogspot.com/2012/08/postgresql-or-modelling-part-3-table.html
En particulier, notez la partie sur les clés primaires et étrangères ne sont pas héritées. Si vous n'aimez pas les limitations de votre SGBD ou si vous utilisez un SGBD qui n'a pas de fonctions relationnelles, une autre option est d'utiliser une alternative suggérée dans l'article ci-dessus et d'utiliser des clés secondaires. Ce serait modelé comme ceci:
CREATE TABLE account
(
account_id INT,
account_type INT NOT NULL,
PRIMARY KEY(account_id),
UNIQUE (account_id, account_type)
);
CREATE TABLE corporate_customer
(
account_id INT,
account_type INT NOT NULL CHECK(account_type IN (1,2)),
company_name VARCHAR(32),
country_code CHAR(2),
PRIMARY KEY(account_id, account_type),
FOREIGN KEY(account_id, account_type) REFERENCES account(account_id, account_type),
UNIQUE(account_id, account_type, company_name)
);
CREATE TABLE private_corp_customer
(
account_id INT,
account_type INT NOT NULL CHECK(account_type = 1),
company_name VARCHAR(32),
company_owner VARCHAR(32),
PRIMARY KEY(account_id, account_type, company_name),
FOREIGN KEY(account_id, account_type, company_name) REFERENCES corporate_customer (account_id, account_type, company_name)
);
CREATE TABLE public_corp_customer
(
account_id INT,
account_type INT NOT NULL CHECK (account_type = 2),
company_name VARCHAR(32),
stock_ticker CHAR(6),
PRIMARY KEY(account_id, account_type, company_name),
FOREIGN KEY(account_id, account_type, company_name)
REFERENCES corporate_customer (account_id, account_type, company_name)
) INHERITS(corporate_customer);
CREATE TABLE government_customer
(
account_id INT,
account_type INT NOT NULL CHECK(account_type = 3),
dept_nbr INT,
country_code CHAR(2),
PRIMARY KEY(account_id, account_type),
FOREIGN KEY(account_id, account_type) REFERENCES account(account_id, account_type),
UNIQUE(account_id, account_type, dept_nbr)
);
La conception ci-dessus a des limites importantes aussi (qui sont également décrits dans l'article ci-dessus). D'une part, bien qu'il ne devrait pas être possible d'avoir un compte qui n'est pas un client privé, public ou gouvernemental, il est possible de le faire; on ne peut avoir que des comptes, des comptes d'entreprises qui ne sont ni publics ni privés ... cela devient un cauchemar à entretenir. Les contraintes CHECK peuvent également nuire aux performances, et vous remarquerez qu'il existe à la fois une duplication de données dans les entités enfants et des informations manquantes dans les entités enfants d'entreprise (code_pays).
Les limites que vous choisissez dépendront de votre fournisseur de SGBD et de la quantité de maux de tête que vous souhaitez gérer.
Si je comprends bien cette approche, mon application devrait gérer un peu l'intégrité des données.Par exemple, il serait possible pour un compte avec type GovernmentCustomer d'avoir plusieurs états financiers. Seules les entreprises clientes devraient avoir cette relation. Ai-je raison? J'ai mis à jour la question pour rendre l'intégrité de l'interface un peu plus claire. –
@TheDeeno, j'ai mis à jour la réponse pour refléter votre entrée. –
@ eed3si9n Merci! Je vais devoir voir si je peux modéliser cela en prenant en compte une contrainte de vérification personnalisée. Donc vous êtes généralement opposé à la table 5 partageant une idée PK? –