2013-06-25 12 views
5

Desidero progettare il modello di dati del mio progetto ma ho un problema nella sezione "Cliente" poiché ho due tipi di clienti: persone fisiche e persone giuridiche Qual è il modo migliore :Il modo migliore per modellare i clienti naturali e legali tutti insieme

Metodo 1: per avere 3 tabelle come questo:

Customers: 
    ID int not null (PK) 
    CustomerType bit not null 
    NaturalPersonID int (FK) 
    LegalPersonID int (FK) 

    NaturalPeople: 
    ID int not null (PK) 
    FirstName nvarchar(50) not null 
    LastName nvarchar(50) not null 
    NationalSecurityNumber char(10) not null 
    ... 

    LegalEntities: 
    ID int not null (PK) 
    CompanyName nvarchar(100) not null 
    RegistrationNumber char(20) not null 
    ... 

che sia NaturalPersonID o LegalPersonID si riempie e l'altro è nullo e CustomerType mostra il tipo di cliente (fisica o giuridica)

Metodo 2: Per avere una tabella con tutti i campi:

ID int not null (PK) 
    CustomerType bit not null 
    FirstName nvarchar(50) 
    LastName nvarchar(50) 
    NationalSecurityNumber char(10) 
    CompanyName nvarchar(100) 
    RegistrationNumber char(20) 
    ... 

Che per ogni cliente alcuni campi sono pieni e gli altri sono nulli

Metodo 3: di avere uno tabella con alcuni campi:

ID int not null (PK) 
    CustomerType bit not null 
    FirstName nvarchar(50) 
    LastName nvarchar(100) 
    NationalSecurityNumber varchar(20) 
    ... 

Quale campo s sono riempiti naturalmente per i clienti naturali. Ma se il cliente è di tipo legale, inseriamo i dati logicamente. Ad esempio, CompanyName nel campo LastName e RegistrationCode nel campo NationalSecurityNumber e il campo FirstName sono nulli.

Metodo 4: qualsiasi altro modo che non ho pensato di e si può suggerire

P.S. Sto implementando il mio database in MS SQL Server 2012

+2

Date un'occhiata al Data Model partito: http://www.tdan.com/view-articles/5014/ – sqlvogel

+0

Come si fa a valutare "migliore"? –

risposta

6

Qualsiasi approccio avrà pro e contro, ognuno di essi sarebbe applicabile in base ai requisiti e all'analisi dell'applicazione.
BTW io preferisco usare Method 1 con alcune considerazioni:

  1. Customer tavolo sarà la tabella di base per NaturalPeople e LegalEntities, chiave primaria del Cliente sarà la chiave primaria degli altri due.
  2. tabella clienti conterrà:
    informazioni in comune dei due altri, come cliente-numero, cliente-tipo ....
    ricerca settori chiave come cliente-full-name (nome standard), quindi è possibile impostare indice su di loro
  3. Evitare di utilizzare un campo per due valori aziendali diverse, come:

    The fields are filled for the natural customers naturally. 
    But if the customer is a Legal one, we put data logically. For example 
    CompanyName in the LastName field and RegistrationCode in 
    the NationalSecurityNumber field and the FirstName field is null. 
    

    prima o poi si soffre se non sepa valutazione dei campi, a causa della violazione first normal form (si pensi che se National_Security_Number) è un valore obbligatorio per NaturalPeople e RegistrationCode è un valore facoltativo per LegalEntities. Non è possibile impostare una chiave univoca o un controllo obbligatorio sul campo.

  4. Altre entità (come account, segni, indirizzo ...) avranno il riferimento solo alla tabella Cliente.

  5. È necessario implementare una ricerca semplice nella tabella Clienti e una ricerca avanzata per clienti legali e naturali.
0

Solo poche parole: non dimenticare che esiste una relazione potenziale tra persone fisiche e persone giuridiche, in cui le persone fisiche appartengono o rappresentano entità legali. Non esiterei ad aggiungere un LegalEntityID FK alla tabella NaturalPeople.

E, per semplicità, non chiamerei un campo chiave esterna "NaturalPersonID" quando questo punta alla tabella "NaturalPeople". Chiamalo NaturalPeopleID, renderà le cose più chiare. Stessa cosa per il campo "LegalPersonID". Potresti anche limitare la denominazione di oggetti/tabelle a "Persone" e "Entità", o "Persone" e "Istituzioni" (questo per evitare qualsiasi confusione tra l'oggetto/tabella Entity e il concetto di Entità nei database relazionali).

1

In questo scenario di solito faccio una tabella Customer che ha una colonna PK e discriminatore CustomerType e due tabelle di dettaglio, una per Natural e una per Legal, ma le chiavi primarie per quelle tabelle aggiuntive sono le stesse di PK del Tabella Customers (simile al metodo uno, ma senza chiavi separate per due sottotipi). In questo modo le query sono più semplici, è possibile imporre un vincolo 1: 0 tra master e dettagli, non ci sono chiavi surrogate e i dati vengono normalizzati.

0

Il metodo 1 è un modello di progettazione noto come .

Il metodo 2 è un modello di progettazione noto come .

È possibile leggere su questi visitando il tag e aprendo la scheda informazioni.

Il metodo 3 ha un nome, che al momento mi sfugge.

Nella tua situazione, vorrei scegliere il metodo 1.

nel metodo 1, hai seguito abbastanza da vicino il modello. L'unica cosa che suggerirei di considerare è la chiave primaria condivisa. L'ereditarietà delle tabelle di classi e la chiave primaria condivisa funzionano bene insieme.

0
create table party_type (
    id serial primary key, 
    description text not null unique 
); 

insert into party_type ('description') values 
('Organization'), 
('Individual'), 
('Automated Agent'); 

create table party (
    id serial primary key, 
    party_type_id int not null references party_type(id), 
    organization_name text null, 
    last_name text null, 
    first_name text null, 
); 

insert into party (party_type_id, organization_name) values (1, 'Acme, Inc'); 
insert into party (party_type_id, last_name, first_name) values (2 'Doe', 'John'); 

create table role_type (
    id serial primary key, 
    description text not null unique 
); 

insert into role_type ('description') values 
('Customer'), 

create table party_role (
    party_id int not null references party(id), 
    role_type_id int not null references party_role_type(id), 
    primary key (party_id, role_type_id) 
); 

/* add both parties as customers: */ 
insert into party_role values (1, 1); 
insert into party_role values (2, 1); 

create table identifier_type (
    id serial primary key, 
    description text not null unique 
); 

insert into identifier_type ('description') values 
('Social Security Number'), 
('Registration Number'); 

create table party_identifier (
    party_id int not null references party(id), 
    identifier_type_id int not null references identifier_type(id), 
    id_number text not null, 
    primary key (party_id, identifier_type_id) 
); 

insert into party_identifier values 
(1, 2, 'some company reg number'), 
(2, 1, 'some ssn')