我目前正在做一个小项目,需要在其中建模以下场景:
场景
想法
我需要一些帮助来找到建模的理想方法,但我有一些想法。
模型
这是我的数据模型v.1.0,请让我知道您的想法。
关注
但是我对此模型有些担心:
如果您有如何更好地建模的技巧,请告诉我!
编辑:数据模型v.1.4
看来您已经将所有这些事物(报价,订单,草稿,发票)建模为与其他所有事物在结构上相同。如果是这种情况,那么您可以将所有类似的属性“推”到一个表中。
create table statement (
stmt_id integer primary key,
stmt_type char(1) not null check (stmt_type in ('d', 'q', 'o', 'i')),
stmt_date date not null default current_date,
customer_id integer not null -- references customer (customer_id)
);
create table statement_line_items (
stmt_id integer not null references statement (stmt_id),
line_item_number integer not null,
-- other columns for line items
primary key (stmt_id, line_item_number)
);
我认为这将适用于您所描述的模型,但是从长远来看,通过将它们建模为超类型/子类型,可以为您提供更好的服务。所有子类型共有的列都被“向上”推入父类型。每个子类型都有一个单独的表,用于显示该子类型唯一的属性。
This SO question及其接受的答案(和评论)说明了博客评论的超类型/子类型设计。 Another question与个人和组织有关。 Yet another与人员和电话号码有关。
稍后。 。 。
这还不完整,但是我没时间了。我知道它不包括订单项。可能错过了其他东西。
-- "Supertype". Comments appear above the column they apply to.
create table statement (
-- Autoincrement or serial is ok here.
stmt_id integer primary key,
stmt_type char(1) unique check (stmt_type in ('d','q','o','i')),
-- Guarantees that only the order_st table can reference rows having
-- stmt_type = 'o', only the invoice_st table can reference rows having
-- stmt_type = 'i', etc.
unique (stmt_id, stmt_type),
stmt_date date not null default current_date,
cust_id integer not null -- references customers (cust_id)
);
-- order "subtype"
create table order_st (
stmt_id integer primary key,
stmt_type char(1) not null default 'o' check (stmt_type = 'o'),
-- Guarantees that this row references a row having stmt_type = 'o'
-- in the table "statement".
unique (stmt_id, stmt_type),
-- Don't cascade deletes. Don't even allow deletes. Every order given
-- an order number must be maintained for accountability, if not for
-- accounting.
foreign key (stmt_id, stmt_type) references statement (stmt_id, stmt_type)
on delete restrict,
-- Autoincrement or serial is *not* ok here, because they can have gaps.
-- Database must account for each order number.
order_num integer not null,
is_canceled boolean not null
default FALSE
);
-- Write triggers, rules, whatever to make this view updatable.
-- You build one view per subtype, joining the supertype and the subtype.
-- Application code uses the updatable views, not the base tables.
create view orders as
select t1.stmt_id, t1.stmt_type, t1.stmt_date, t1.cust_id,
t2.order_num, t2.is_canceled
from statement t1
inner join order_st t2 on (t1.stmt_id = t2.stmt_id);
应该有一个表“ quotelines”,它类似于“ orderlines”。同样,您应该有一个“发票行”表。所有这些表均应具有“价格”字段(名义上将是零件的默认价格)以及“折扣”字段。您还可以在“报价”,“订单”和“发票”表中添加“折扣”字段,以处理现金折扣或特价商品之类的事情。尽管您写了什么,但最好还是有单独的表格,因为报价中的金额和价格可能与客户实际订购的金额不匹配,并且再次与您实际提供的金额可能不相同。我不确定'草稿'表是什么-您可以将'草稿'和'发票'表包含相同的信息,而其中一个字段包含发票状态-草稿或最终稿。将发票数据与订单数据分开很重要,因为大概您将根据自己的收入(发票)来纳税。
“报价”,“订单”和“发票”都应具有一个字段(外键),其中包含销售代表的价值;该字段将指向不存在的“ SalesRep”表。您也可以在“客户”表中添加“ salesrep”字段,该字段指向客户的默认代表。该值将被复制到“ quotes”表中,但是如果默认值的不同代表给出了报价,则可以将其更改。同样,当从报价单中订购订单并从订单中订购发票时,应复制此字段。
我可能会添加更多,但是这完全取决于您要制作的系统的复杂程度和详细程度。如果汽车是根据其选项进行配置并相应定价的,则可能需要添加某种形式的“物料清单”。