Модель данных ER - запутанная диаграммой - PullRequest
Новая
       2

Модель данных ER - запутанная диаграммой

1 голос
/ 18 февраля 2010

меня немного смущает эта диаграмма http://www.b -eye-network.com / images / content / i030ht0104.gif (последняя диаграмма в статье)

1 - ВВ таблице «УЧЕТНАЯ ЗАПИСЬ» показаны «DebitEntry» и «CreditEntry». I) это два столбца или
ii) это две строки данных?или iii) это две отдельные таблицы, Acounting_entry_credit и Accounting_entry_debit?

Тот же вопрос с таблицей "ACCOUNT", она показывает учетную запись актива, учетную запись жизнеспособности, учетную запись Equityэто 3 столбца или 3 ряда?

Источник: http://www.tdan.com/view-articles/5227/

Ответы [ 3 ]

1 голос
/ 18 февраля 2010

В принципе, ни один здравомыслящий дизайн никогда бы не поместил два разных значения данных, таких как «ЗАДЕРЖКА ВХОДА» и «ВХОД В КРЕДИТ» в одном столбце.

Похоже на поля «ВХОД В ДЕБЕТ» и «ВХОД В КРЕДИТ»это таблицы, которые «наследуются» от таблицы «Учетная запись».Как бы я это интерпретировал, «DEBIT ENTRY» и «CREDIT ENTRY» - это таблицы, которые содержат столбцы ID, AMOUNT и OPERATOR.Строки в этих таблицах затем указываются в таблице «СЧЕТНАЯ СДЕЛКА».

Таким образом, каждый большой блок определяет «тип» таблицы, а каждый вложенный блок определяет конкретную таблицу в ERD.Я предполагаю, что они нарисовали его таким образом, чтобы им не приходилось повторять определения столбцов снова и снова.

Тогда у каждого типа «Счета» (Актив, Ответственность и Капитал) есть идентификатор и поле COMMENT.У каждого из них также есть связь с таблицей «ТИП СЧЕТА», которая содержит номер счета и описание.

0 голосов
/ 19 февраля 2010 
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

<--- Поначалу я тоже думал, что это так, но если внимательно присмотреться к таблице "ACCOUNTING_TRANSACTION", на самом деле не имеет смысла иметь одно отношение транзакции, которое будет одновременно "кредитным и дебетовым". </p>

Таким образом, «DebitEntry» и «CreditEntry» на самом деле являются двумя отдельными таблицами, но они ссылаются на один и тот же «идентификатор транзакции бухгалтерского учета», который имеет смысл: «Бухгалтерская транзакция должна состоять из одной или нескольких дебетовых записей и должна состоять из одной или нескольких кредитных записей. "

Пример 

>>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
0 голосов
/ 18 февраля 2010

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

Но в общих чертах,статья гласит:

Бухгалтерская транзакция должна состоять из одной или нескольких дебетовых записей и состоять из одной или нескольких кредитных записей.

Для меня это выглядит и звучит как два внешних ключа, которые ссылаются на одну и ту же таблицу: 

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)
);

с соответствующими ограничениями, обеспечивающими условие, указанное в тексте.Но, конечно, есть и лучшие способы разработки этого.Например: 

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

с entry_type, означающим кредит или дебет, и снова соответствующие ограничения.

Редактировать: Обычно вы ожидаете, что ERD такого типа будет означать другой типотношений: это от коллекции до фиксированного количества компонентов, которые имеют одинаковый тип, но имеют разные значения в контексте коллекции.Классическим примером является этап полета, который имеет ровно один аэропорт вылета и (надеюсь) ровно один аэропорт назначения, где, конечно, аэропорт является аэропортом. 

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
);

Обратите внимание на разницу в том, кто на кого ссылается.Для модели в статье это будет означать, что accounting_transaction ссылается ровно на один debit_entry и ровно на один credit_entry, что, по-видимому, не соответствует намерениям автора.

...