ขั้นตอนการออกแบบ ER Diagram
Download
Report
Transcript ขั้นตอนการออกแบบ ER Diagram
Design Database : e-Commerce
Company
THINAPHAN NITHIYUWITH
Email : [email protected]
LOGO
Contents
1
2
การออกแบบ Relation Database
3
ขั้นตอนการออกแบบ E-R Diagram
4
Mapping E-R Diagram to Relation
5
2
การออกแบบฐานข้ อมูล
สรุป Q&A
Designing Databases is . . .
การออกแบบฐานข้ อมูล (Designing
Databases) มีความสาคัญต่อการจัดการ
ระบบฐานข้อมูล (DBMS) ทั้งนี้เนื่องจากข้อมูล
ที่อยูภ่ ายในฐานข้อมูลจะต้องศึกษาถึงความสัมพันธ์
ของข้อมูล โครงสร้างของข้อมูลการเข้าถึงข้อมูลและ
กระบวนการที่โปรแกรมประยุกต์จะเรี ยกใช้
ฐานข้อมูล
3
ขั้นตอนการออกแบบ Relation Database
ขั้นตอนการดาเนินการ การออกแบบฐานข้ อมูลเชิงสั มพันธ์ มี 6 ขั้นตอน
การรวบรวมและวิเคราะห์ความต้องการในการใช้ขอ้ มูล
การเลือกระบบจัดการฐานข้อมูล
การออกแบบฐานข้อมูลในระดับแนวคิด
การนาฐานข้อมูลที่ออกแบบในระดับแนวคิดเข้าสู่ ระบบจัดการฐานข้อมูล
การออกแบบฐานข้อมูลในระดับกายภาพ
การนาฐานข้อมูลไปใช้และการประเมินผล
4
ขั้นตอนการออกแบบ Relation Database
การรวบรวมและวิเคราะห์ ความต้ องการใน
การใช้ ข้อมูล
ขั้นตอนนี้ขอ้ มูลจะได้มาจากแบบฟอร์ มต่างๆ
เช่น ใบสั่งซื้ อ, ใบเสร็ จรับเงิน , หรื อหน้าตา
รายงานที่ตอ้ งการแสดงผล เช่น รายงานลูกค้า
ที่ชาระเงินแล้ว, รายงานการสัง่ ซื้ อสิ นค้า
ประจาวัน (แต่ในเมื่อเรามีการออกแบบ DFD
มาแล้ว ก็เอามาใช้ให้เกิดประโยชน์ซะเลย) แต่
ต้องระวังว่าข้อมูลที่เกิดขึ้นในการทา DFD ก็
อาจมีไม่ครบ ฉะนั้นต้องพิจารณาจากข้อมูล
แบบฟอร์ม และรายงานประกอบด้วยนะ
5
ขั้นตอนการออกแบบ Relation Database
การเลือกระบบจัดการฐานข้ อมูล
ขั้นตอนนี้คุณต้องตัดสิ นใจว่าคุณจะเลือกใช้ DBMS ตัวไหน เช่น
SQLServer, MS Access, MySQL, Oracle ฯ (ไม่ตอ้ งคิดมาก คุณก็เอา
มาจากบทที่ 1 ของคุณ นอกจากลองไปศึกษาดูแล้วมีเหตุให้ตอ้ งเปลี่ยน
ก็เปลี่ยนได้)
ทาไมต้องเลือก ? เพราะว่าจะเอามากาหนดชนิดของข้อมูล ตอนทาเป็ น
ตารางจ้า
6
ขั้นตอนการออกแบบ Relation Database
การออกแบบฐานข้ อมูลในระดับแนวคิด
การออกแบบฐานข้อมูลในระดับแนวความคิด หรื อใน
ระดับตรรกะ เป็ นขั้นตอนการออกแบบความสัมพันธ์
ระหว่างข้อมูลในระบบโดยใช้แบบจาลองข้อมูลเชิง
สัมพันธ์ ซึ่งอธิบายโดยใช้แผนภาพแสดงความสัมพันธ์
ระหว่างข้อมูล (E-R Diagram) จากแผนภาพ ER Diagram นามาสร้างเป็ นตารางข้อมูล
(Mapping E-R Diagram to
Relation) และใช้ทฤษฏีการ Normalization
เพื่อเป็ นการรับประกันว่าข้อมูลมีความซ้ าซ้อนกันน้อย
ที่สุด
7
ขั้นตอนการออกแบบ Relation Database
กาหนด Entity
Strong Entity
Weak Entity
กาหนด Attribute
Composite attribute
Simple attribute
Single-value attribute
Multivalued attributes
Derived attributes
8
กาหนด Primary Key
กาหนด Relationship
1:1
1:M
M:N
ชนิดความสั มพันธ์
Unary/Recursive
Binary
Ternary
EER
Symbol (Chen)
Entity
Weak Entity
Relationship
Owner Relationship
9
Symbol (Chen)
Attribute
Multivalue Attribute
Primary Key
Composite Attribute
Derived Attribute
10
Symbol (Chen)
partial
E1
E1
Total
R
1
R
E2
N
Cardinality Ratio
11
E2
ขั้นตอนการออกแบบ E-R Diagram : e-Commerce
1. กาหนด Entity
Entity คือ ข้อมูลที่เราสนใจจะจัดเก็บข้อมูล
ข้อมูลหาได้จากไหน ?
• อยากที่เคยบอกไว้ในสไลด์ที่ 5 ข้อมูลที่จะจัดเก็บได้มาจาก DFD และ
แบบฟอร์ม รายงาน ดังนั้น หากเราพิจารณา DFD ตรง data store ที่
เป็ นสัญลักษณ์
นี้ ก็นามากาหนดเป็ น Entity เบื้องต้นได้เลย
12
การออกแบบ E-R Diagram : e-Commerce
ฉะนั้น จากรู ป DFD จะได้ เอนทิตเี้ บือ้ งต้ นทั้งหมด 5 เอนทิตี้
ต่อมาต้องพิจารณาว่า ทั้ง 5 เอนทิต้ ี
Strong หรื อ week โดย
พิจารณาดังนี้
การที่เราขายสิ นค้าหมายความว่า
เราต้องมีคนซื้ อ(สมาชิก) และต้อง
มีสินค้าให้เขาซื้ อ ฉะนั้นข้อมูล
ตรงนี้แหละคือ strong entity
ส่ วนข้อมูลอื่น ๆ จะเกิดขึ้นได้ตอ้ ง
มาจากการที่ลูกค้าซื้ อของทาให้เกิด
รายการซื้ อ และเมื่อลูกค้ามาชาระเงิน
ตามรายการซื้ อทาให้เกิดรายการชาระ
เงิน เมื่อมีรายการชาระเงินเข้ามา ก็ทาให้
เกิดรายการส่ งสิ นค้า จานวนสิ นค้าก็
ลดลง
13
การออกแบบ E-R Diagram : e-Commerce
ฉะนั้นตอนนีส้ ิ่ งที่ได้ คอื เป็ น strong entity 2 ตัว คือ สมาชิก กับ สิ นค้ า
สมาชิก
member
สิ นค้ า
product
ส่ วนอีก 3 ตัว มาพิจารณากันจากเหตุการณ์ ต่อไปนี้ จะเห็นได้ ว่า
รายการซื้อสิ นค้ า จะเกิดขึ้นได้กต็ ่อเมื่อมีสมาชิกมาซื้ อสิ นค้า
รายการชาระเงิน จะเกิดขึ้นได้กต็ ่อเมื่อ มีรายการซื้ อสิ นค้าเกิดขึ้น สมาชิกถึงชาระ
เงิน
รายการส่ งสิ นค้ า จะเกิดขึ้นได้กต็ ่อเมื่อ สมาชิกมีการชาระเงินแล้ว
14
เมือ่ พิจารณาจาก 3 เหตุการณ์ แล้ ว จะเห็นได้ ว่า ข้ อมูลทั้ง 3 มีการขึน้ ต่ อกัน ไม่
สามารถเกิดขึน้ เองได้ ต้องพึง่ พาข้ อมูลอืน่ ถึงจะเกิดได้
เมือ่ เป็ นเช่ นนี้ ข้ อมูลทั้ง 3 ต้ องเป็ น week entity
รายการสั่ งซื้อ
15
order
รายการชาระเงิน
payment
รายการส่ งสิ นค้ า
Deliver
ขั้นตอนการออกแบบ E-R Diagram : e-Commerce
2. กาหนด attribute และ primary key
attribute คือ รายละเอียด ข้อมูลที่เราต้องการเก็บในเอนทิต้ ีน้ นั ๆ เช่น เอนทิต้ ีสมาชิก
ประกอบด้วย รหัส, ชื่อ, ที่อยู,่ เบอร์โทร, อีเมล์
ข้อมูลหาได้จากไหน ?
• ได้มาจากแบบฟอร์ม รายงาน เราอาจเพิ่มรายเอียดเสริ มเข้าไปได้ เช่น จากฟอร์มใบสัง่
ซื้อสิ นค้า จะเห็นว่าข้อมูลสมาชิกประกอบด้วย ชื่อ, ที่อยู่ แต่เราต้องการเก็บข้อมูลเพิ่ม
เบอร์โทร, อีเมล์ เพื่อสะดวกในการติดต่อ เป็ นต้น
นอกจากจะกาหนด attribute แล้วควรต้องรู้วา่ ข้อมูลที่จะจัดเก็บควรเป็ น attribute
แบบไหน เช่น ข้อมูลนั้นเป็ นข้อมูลที่มีค่าได้หลายค่ารึ เปล่า ยกตัวอย่าง ข้อมูลเบอร์โทรศัพท์
เพราะคน ๆ หนึ่งมีเบอร์โทรได้หลายเบอร์ อันนี้ข้ ึนกับความต้องการของ user หรื อเป็ น
ข้อมูลที่ได้จากการคานวณ เช่น รวมจานวนสิ นค้า, ราคารวม, ราคาสิ นค้ารวม
16
ตัวอย่ าง Report
ชื่อลูกค้ า
.........................................................................
รายการสั่งซื้อสินค้ า
เลขทีใ่ บสั่งซื้อ วันทีส่ ั่งซื้อ สถานะ
xxxxx
xxxxx xxxx
xxxxx
xxxxx xxxx
xxxxx
xxxxx xxxx
xxxxx
xxxxx xxxx
xxxxx
xxxxx xxxx
xxxxx
xxxxx xxxx
17
ชื่อลูกค้า
.........................................................................
แจ้ งชาระเงิน
เลขที่ใบสั่งซื้อ วันที่สั่งซื้อ สถานะ
xxxxx
xxxxx xxxx
xxxxx
xxxxx xxxx
xxxxx
xxxxx xxxx
ใบสั่ งซื้อสิ นค้ า
ร้ าน..................
ชื่อลูกค้ า................................................
ทีอ่ ยู่ ....................................................
รหัสสิ นค้ า
xxxxx
ชื่อสิ นค้ า
วันที.่ ................เวลา..........
เลขทีใ่ บสั่ งซื้อ......................
รายการสั่ งซื้อสิ นค้ า
จานวน ราคา ราคารวม
xxxxxxxxxxxxxxxxxxxx
xx
xxx xx,xxx
รวมสิ นค้ า ................ ชิ้น
ราคาสิ นค้ ารวม .................. บาท
ค่ าจัดส่ ง ................... บาท
รวมเป็ นเงินทั้งสิ้น ...................... บาท
หมายเหตุ ...............................................................................................................................
......................................................................................................
18
ขั้นตอนการออกแบบ E-R Diagram : e-Commerce
2. กาหนด attribute และ primary key
Primary key คือ แอทริ บิวต์ที่สามารถบ่งบอกความเป็ นเอกลักษณ์
หรื อหนึ่งเดียวได้ ไม่มีใครซ้ า อาจเป็ นแอทริ บิวต์เดียว หรื อหลาย ๆ แอทริ บิวต์
ประกอบกันเพื่อให้มีคุณสมบัติดงั กล่าว
ดังนั้นจาก entity ทั้ง 5 สามารถกาหนดแอทริ บิวต์ และไพรมารี คีย ์ ได้ดงั นี้
19
Address
Name
price
E-mail
PID
ID
product
member
o_amount
o_time
o_date
amount
pname
Phone
t_price
pay_detail
pay_date
pay_time
slip
tt_price
pay_id
p_status
t_unit
portage
payment
net
o_id
comment
order
o_status
d_date
d_time
id_ems
d_id
delivery
20
ขั้นตอนการออกแบบ E-R Diagram : e-Commerce
3. กาหนดความสั มพันธ์ Relation
ความสัมพันธ์ได้มาจากไหน ?
ในขั้นนี้ให้พิจารณาจากความเป็ นจริ งของระบบงาน เช่น กรณี น้ ีเป็ นเรื่ องการ
ซื้ อสิ นค้า ฉะนั้นต้องมีความสัมพันธ์ระหว่าง คนซื้ อ(สมาชิก) กับ สิ นค้า เมื่อ
จับคู่เอนทิต้ ีได้แล้ว ก็ให้พิจารณาถึงสัดส่ วนความสัมพันธ์ ว่าเป็ น 1:1 1:m
หรื อ m:n
นอกจากพิจารณาจากความเป็ นจริ งแล้ว ก็สามารถพิจารณาจาก DFD ได้อีก
ด้วย
21
ขั้นตอนการออกแบบ E-R Diagram : e-Commerce
3. กาหนดความสั มพันธ์ Relation
คราวนี้มาลองคิดถึงสัดส่ วนความสัมพันธ์วา่ มันต้องเป็ นยังไง
เวลาอ่านความสัมพันธ์ตอ้ งเทียบฝั่งที่อ่านเป็ น 1 เสมอ
สมาชิก 1 คนสามารถซื้ อ สิ นค้า ได้ หลายสิ นค้า
สิ นค้า 1 ตัว ก็สามารถถูกซื้ อ โดยสมาชิก ได้ หลายคน
member
22
n
buy
m
product
ขั้นตอนการออกแบบ E-R Diagram : e-Commerce
จะเห็นว่ าตรงในส่ วน buy มีสี่เหลีย่ มมาครอบ จะเกิดเอนทิตใี้ หม่ ขนึ้ แล้วเป็ น
เอนทิตอี้ ะไรดีล่ะ แล้วจะมีแอทริบิวต์ อะไรเกิดขึน้ บ้ าง ?
ใช้ DFD มาช่ วยในการพิจารณา
• จาก DFD จะเห็นว่ามีเส้นวิง่
จากสมาชิก และสิ นค้า เข้าโพเซส 3.0
คือซื้ อสิ นค้า ทาให้เกิดแฟ้มรายการซื้อ
เกิดขั้น
member
23
n
buy
m
product
ขั้นตอนการออกแบบ E-R Diagram : e-Commerce
n
member
buy
1
member
m
buy
1
member
m
m
buy
order
order
n
product
m
buy
1
m
have
product
order_detail
m
have
1
product
24
ขั้นตอนการออกแบบ E-R Diagram : e-Commerce
สรุ ปจากความสั มพันธ์ ระหว่ าง สมาชิก กับ สิ นค้ า ทาให้ เกิด รายการซือ้ และจาก
รายการซื้อ ทาให้ เกิด รายละเอียดการซื้อ
ในส่ วนของ order จะเหลือแอทริบิวต์ ทมี่ ีค่าเพียงค่ าเดียว คือ วันที่ซื้อ เวลาทีซ่ ื้อ
ค่ าจัดส่ ง หมายเหตุ ส่ วนทีเ่ หลือทั้งหมดจะไปอยู่ทเี่ อนทิตี้ order_detail
ในส่ วนของ order_detail ประกอบด้ วยแอทริบิวต์ จานวนที่ซื้อ
o_num
member
1
m
buy
order
1
have
o_status
o_id
comment
o_date
m
order_detail
m
have
portage
o_time
1
product
25
ขั้นตอนการออกแบบ E-R Diagram : e-Commerce
จาก DFD จะเห็นว่ า มีเส้ นจากแฟ้มรายการซื้อ วิง่ เข้ าโพรเซสแจ้ งชาระเงิน
และจากโพรเซสแจ้ งชาระเงิน วิง่ เข้ าแฟ้ม รายการชาระเงิน จึงทาให้ เราพอจะทราบ
ทีม่ าของแฟ้มรายการชาระเงิน ว่ ามีความสั มพันธ์ กบั แฟ้มรายการซื้อ โดย
order
have
payment
26
ขั้นตอนการออกแบบ E-R Diagram : e-Commerce
พิจารณาสั ดส่ วนความสั มพันธ์
รายการซื้อ 1 ใบ มีขอ้ มูลการชาระเงินได้ 1 รายการ
รายการชาระเงิน 1 รายการ เป็ นของ ใบรายการซื้อ 1 ใบ
เมื่อเป็ นความสัมพันธ์แบบ 1:1 ควรจะพิจารณาถึงค่าต่าสุ ด
และสูง
เมื่อมีใบรายการซื้ อ น้อยที่สุดอาจจะไม่มีขอ้ มูลการชาระเงิน
ก็ได้ แต่ถา้ มี ๆ ได้สุงสุ ดแค่ 1 รายการ
ตรงนี้โอกาสเป็ นไปได้คือ (0,1) ในทางกลับกัน ข้อมูลการชาระ
เงิน จะมีได้ตอ้ งมีใบรายการซื้ ออย่างน้อยที่สุด 1 ใบ มาก
ที่สุด 1 ใบ โอกาสที่เป็ นไปได้คือ (1,1)
27
order
(0,1)
have
(1,1)
payment
ขั้นตอนการออกแบบ E-R Diagram : e-Commerce
ต่ อมาจาก DFD จะเห็นว่ า มีเส้ นจากแฟ้มรายการชาระเงิน วิง่ เข้ าโพรเซส
จัดส่ งสิ นค้ า และวิง่ เข้ าแฟ้ม รายการส่ งสิ นค้ า จึงทาให้ เราพอจะทราบทีม่ าของแฟ้ม
รายการส่ งสิ นค้ า ว่ ามีความสั มพันธ์ กบั แฟ้มรายการชาระเงิน โดยแฟ้มรายการส่ ง
สิ นค้ าจะเกิดขึน้ ได้ กต็ ่ อเมือ่ มีแฟ้มรายการชาระเงิน
payment
28
have
delivery
ขั้นตอนการออกแบบ E-R Diagram : e-Commerce
พิจารณาสั ดส่ วนความสั มพันธ์
รายการชาระเงิน 1 รายการ มีขอ้ มูลใบรายการส่ งสิ นค้าได้ 1 ใบ
ใบรายการส่ งสิ นค้า 1 ใบ เป็ นของ รายการชาระเงิน 1 รายการ
เมื่อเป็ นความสัมพันธ์แบบ 1:1 ควรจะพิจารณาถึงค่าต่าสุ ดและสูง
เมื่อมีรายการชาระเงิน 1 รายการ น้อยที่สุดอาจจะยังไม่มีขอ้ มูลการส่ งสิ นค้าก็ได้ แต่ถา้ มี ๆ
ได้สุงสุ ดแค่ 1 รายการ ตรงนี้โอกาสเป็ นไปได้คือ (0,1) ในทางกลับกัน ข้อมูลส่ งสิ นค้าจะมีได้
ต้องมีรายการชาระเงินอย่างน้อยที่สุด 1 รายการ มากที่สุด 1 รายการ โอกาสที่เป็ นไปได้คือ
(1,1)
payment
29
(0,1)
have
(1,1)
delivery
pay_time
pay_date
d_date
d_time
pay_detail
slip
pay_id
P_status
payment
(1,1)
delivery
Address
Phone
have
o_num
E-mail
member
have
id_ems
(1,1)
Name
ID
(0,1)
d_id
1
(0,1)
m
buy
order
1
m
have
order_detail
m
o_status
o_id
have
comment
o_date
portage
o_time
1
product
pid
price
pname
30
แผนภาพ E-R Diagram ระบบ e-Commerce
amount
Mapping E-R Diagram to Relation
พิจารณาความสั มพันธ์ ดังนี้
ให้พิจารณาที่ชนิ ดของเอนทิต้ ี จะเห็นว่า ใน e-r ตัวอย่างของเรามีเอนทิต้ ี 2
ประเภท คือ strong entity กับ week entity ดังนั้นให้ ดูที่
week ก่อนว่า ที่week มี pk เกิดขึ้นไหม ?
order_detail
• หากไม่มี เช่น ตัวอย่างเอนทิต้ ี
จะเห็นว่ามีแอทริ บิวต์ o_num
(จานวนที่ซ้ือ) ซึ่งไม่สามารถเป็ น pk ได้ หากเป็ นลักษณะเช่นนี้ วิธีการแปลง
เป็ น relation ทาได้โดยนา pk ของเอนทิต้ ีที่เป็ นแม่มาเป็ น pk ร่ วมที่
เอนทิต้ ีลูก ทาให้เกิดรหัสรายการใบซื้อ (o_id) กับรหัสสิ นค้า(pid)มาเป็ น
pk ร่ วมที่เอนทิต้ ี รายละเอียดรายการซื้อ (order_detail)
1 : m หรื อ m : 1 ให้นา pk ของ ฝั่ง 1 ไปเป็ น fk ของฝั่ง m
31
Mapping E-R Diagram to Relation
หากมีแอทริบิวต์ ที่เป็ น pk เกิดขึน
้ ให้ พจิ ารณาดูสัดส่ วนความสั มพันธ์
1 : m หรื อ m : 1 ให้นา pk ของ ฝั่ง 1 ไปเป็ น fk ของฝั่ง m เช่น
1
member
m
buy
order
จะได้ id ของ member ไปปรากฏเพิ่มที่ order เป็ น fk
1 : 1 ให้พิจารณาค่าต่าสุ ดและสู งสุ ดของข้อมูล เพื่อหลีกเลี่ยงการเกิดค่า null
• ให้นา pk ของฝั่งที่มีโอกาสเกิดค่า 0 ไปเป็ น fk ฝั่ง 1
32
Mapping E-R Diagram to Relation
ก่อน Mapping E-R Diagram to Relation
33
Mapping E-R Diagram to Relation
หลัง Mapping E-R Diagram to Relation
34
Data Dictionary
การทา Data Dictionary คือ การกาหนดรายละเอียดให้ กบั Relation
ดังนี้
member (สมาชิก)
ลาดับ
1
2
3
4
5
35
แอทริบิวต์
id
name
address
phone
email
ความหมาย
รหัสสมาชิก
ชนิด
int
ขนาด คีย์
หมายเหตุ
4
pk auto_number
ชื่อ-สกุลสมาชิก
varchar
50
not null
ทีอ่ ยู่
varchar
50
not null
เบอร์ โทรศัพท์
varchar
15
null
อีเมล์
varchar
20
null
Data Dictionary
order (ใบรายการซื้อสิ นค้ า)
ลาดับ แอทริบิวต์
1
2
3
4
5
6
o_id
o_date
o_time
portage
comment
o_status
7
id
36
ความหมาย
ชนิด
รหัสใบรายการซื้อสิ นค้ า int
ขนาด คีย์
หมายเหตุ
4
pk auto_number
วันทีซ่ ื้อ
varchar 50
not null
เวลาทีซ่ ื้อ
varchar 50
not null
ค่ าขนส่ ง
int
not null
หมายเหตุ
varchar 255
null
สถานะการชาระเงิน
char
1
รหัสสมาชิก
int
4
not null
0 = ยังไม่ ชาระเงิน
1 = ชาระเงินแล้ ว
ตาราง member
4
fk
Data Dictionary
order_detail (รายละเอียดใบรายการซื้อสิ นค้ า)
ลาดับ แอทริบิวต์
1
2
3
37
o_id
pid
o_num
ความหมาย
ชนิด
รหัสใบรายการซื้อสิ นค้ า int
ขนาด คีย์
หมายเหตุ
4
pk auto_number
รหัสสิ นค้ า
varchar 6
จานวนทีซ่ ื้อ
int
6
pk
not null
Data Dictionary
product (สิ นค้ า)
ลาดับ แอทริบิวต์
1
2
3
4
38
pid
pname
amount
price
ความหมาย
รหัสสิ นค้ า
ชนิด ขนาด คีย์
หมายเหตุ
varchar 6
pk auto_number
ชื่อสิ นค้ า
varchar 255
not null
จานวนคงเหลือ
int
not null
ราคาขาย
decimal 6,2
4
not null
Data Dictionary
payment (การชาระเงิน)
ลาดับ แอทริบิวต์
ความหมาย
รหัสการชาระเงิน
1 pay_id
ชนิด
int
ขนาด คีย์
หมายเหตุ
4
pk auto_number
2
3
4
5
pay_detail
pay_date
pay_time
slip
รายละเอียดการชาระเงิน text
not null
วันทีช่ าระเงิน
varchar 50
not null
เวลาทีช่ าระเงิน
varchar 50
not null
slipธนาคาร
varchar 255
6
p_status
สถานะการจัดส่ งสิ นค้ า
char
7
o_id
รหัสใบรายการซื้อสิ นค้ า int
not null ,รู ปภาพ สกุล
jpg,gif
not null
0 = ยังไม่ จัดส่ งสิ นค้ า
1 = จัดส่ งสิ นค้ าแล้ ว
ตาราง order
39
1
4
fk
Data Dictionary
delivery (การจัดส่ งสิ นค้ า)
ลาดับ แอทริบิวต์
1
2
3
4
5
40
d_id
d_date
d_time
id_ems
pay_id
ความหมาย
รหัสสิ นค้ า
ชนิด
int
วันทีจ่ ัดส่ งสิ นค้ า
varchar 50
not null
เวลาทีจ่ ัดส่ งสิ นค้ า
varchar 50
not null
หมายเลขพัสดุหรือems varchar 20
not null
รหัสการชาระเงิน
int
ขนาด คีย์
หมายเหตุ
4
pk auto_number
4
fk
ตาราง payment
db_commerce : MySQL
phpMyAdmin จัดการสร้ าง Database และ Relation
Database : db_commerce ประกอบด้ วย 6 ตาราง
41
Table : member
1
42
Table : order
2
43
Table : product
3
44
Table : order_detail
4
45
Table : payment
5
46
Table : delivery
6
47
Company
LOGO