2010-02-18 10 views
1

im un peu confus par ce diagramme http://www.b-eye-network.com/images/content/i030ht0104.gif (diagramme dernier dans l'article)ER Modèle de données - confondu par diagramme

1 - Dans la « Saisie comptable » tableau il montre « DebitEntry » et « CreditEntry » i) est cette deux colonne ou
ii) est ce deux lignes de données? ou iii) s'agit-il de deux tables distinctes, Acounting_entry_credit et Accounting_entry_debit?

Même question avec la table "ACCOUNT", elle montre le compte d'actif, le compte livaisons, le compte d'équité? sont-ils 3 colonnes ou sont-ils 3 rangées?

Source: http://www.tdan.com/view-articles/5227/

Répondre

0
create table accounting_entry (
    id integer primary key, 
    amount float not null, 
    operator text, 
    credit_id integer references accounting_transaction(id), 
    debit_id integer references accounting_transaction(id) 
);z 

< --- Je pensais que c'était comme ça au début aussi, mais en regardant de près table « ACCOUNTING_TRANSACTION », elle ne tenait pas vraiment logique d'avoir une seule relation de transaction « à la fois crédit et de débit » à le même temps. Donc "DebitEntry" et "CreditEntry" sont en fait deux tables séparées, mais elles font référence au même "Accounting Transaction ID" qui aurait du sens, "Une transaction comptable doit être composée d'une ou plusieurs entrées de débit et elle doit être composé d'une ou de plusieurs écritures de crédit. "

Exemple

>>ACCOUNTING_ENTRY_DEBIT 
ID---ACCOUNTTRANSACTIONID-----ACCOUNTID---------AMOUNT-----OPERATOR 
102--------2------------------------1---------------1,000-----Plus 

>>ACCOUNTING_ENTRY_CREDIT 
ID---ACCOUNTTRANSACTIONID-----ACCOUNTID---------AMOUNT-----OPERATOR 
105--------2------------------------2---------------1,000-----Minus 
1

En principe, aucune conception saine d'esprit ne pourrait jamais mettre deux valeurs de données différentes comme « ENTRÉE DE DÉBIT » et « ENTRÉE DE CRÉDIT » dans la même colonne.

Il semble que les champs "DEBIT ENTRY" et "CREDIT ENTRY" sont des tables qui "héritent" du tableau "Accounting Entry". La façon dont j'interpréterais ceci est à la fois «ENTRÉE DE DÉBIT» et «ENTRÉE DE CRÉDIT» sont des tables qui contiennent les colonnes ID, AMOUNT et OPERATOR. Les lignes de ces tables sont ensuite référencées par la table "ACCOUNTING TRANSACTION". Il semble donc que chaque grande boîte définit un «type» de table et que chaque boîte imbriquée définit une table spécifique dans la DRE. Je suppose qu'ils l'ont dessiné de telle sorte qu'ils n'auraient pas à répéter les définitions des colonnes encore et encore. Ensuite, chaque type de compte (actif, passif, & Equity) a un ID et un champ COMMENT. Ils ont également chacun une relation avec le tableau "TYPE DE COMPTE" qui contient le numéro de compte et une description.

0

C'est un peu trouble parce que l'article ne cesse de parler de supertypes et de sous-types et n'indique jamais vraiment lequel des moyens possibles pour implement inheritance in databases est voulu.

Mais en termes généraux, l'article stipule:

Une opération comptable doit être composé d'une ou plusieurs entrées de débit et il doit être composé d'une ou plusieurs entrées de crédit.

Pour moi, cela ressemble et ressemble à deux clés étrangères qui font référence à la même table:

create table accounting_transaction (
    id integer primary key, 
    date date not null, 
    description text 
); 
create table accounting_entry (
    id integer primary key, 
    amount float not null, 
    operator text, 
    credit_id integer references accounting_transaction(id), 
    debit_id integer references accounting_transaction(id) 
); 

avec des contraintes appropriées garantissant la condition énoncée dans le texte. Mais bien sûr, il y a de meilleures façons de concevoir cela. Par exemple:

create table accounting_entry (
    id integer primary key, 
    amount float not null, 
    operator text, 
    entry_type integer, 
    transaction_id integer references accounting_transaction(id) 
); 

avec entry_type signifiant crédit ou de débit, et des contraintes encore appropriées. Edit: Normalement, une ERD de ce type devrait normalement indiquer un type de relation différent: celui d'une collection à un nombre fixe de composants qui sont du même type mais ont des significations différentes dans le contexte de la collection. L'exemple classique est une étape de vol qui a exactement un aéroport de départ et (espérons-le) exactement un aéroport de destination, où bien sûr un aéroport est un aéroport.

create table flight_leg(
    id integer primary key, 
    departure_airport integer references airport(id), 
    destination_airport integer references airport(id) 
); 
create table airport(
    id integer primary key, 
    iata_code varchar(3) not null, 
    name text 
); 

Notez la différence dans qui fait référence à qui.Pour le modèle dans l'article cela signifierait qu'un accounting_transaction référence exactement un debit_entry et exactement un credit_entry, ce qui ne semble pas être l'intention de l'auteur.

Questions connexes