ไปเจอมาจาก narisa เห็นว่าน่าสนใจ ขอบคุณเหล่าทวยเทพแห่ง narisa ด้วยนะครับ
โดยเฉพาะเจ้าของคุณ  minimalist
http://www.narisa.com/forums/index.php?showtopic=14372


 ตอนทำ Analysis เราต้องระบุว่าแต่ละคลาสที่หาได้เป็นคลาสชนิดใด

Analysis Class มี 3 ประเภท คือ
1. Boundary Class คือส่วนติดต่อระหว่าง Actor กับ Use Case หรือ เอาให้ง่ายขึ้นคือ ส่วนติดต่อระหว่างโปรแกรมกับคนหรืออุปกรณ์หรือโปรแกรมอื่น เช่น หน้าจอ อินเตอร์เฟสใน OO หรือใน Java
2. Control Class คือส่วนที่ทำหน้าที่ประมวลผล Logic หลักของ Use Case นั้น
3. Entity Class คือส่วนที่ Represent ข้อมูลที่การประมวลผลใน Use Case นั้นมีการเรียกใช้ (ปกติคือ Read / Write)

Object Data Model แบบพื้นฐานก็คือการดึงเอาพวก Entity Class ออกมารวมกันใน Class Diagram เดียว กำหนด
ความสัมพันธ์พวก Association, Composition, Aggregation, Generalization ให้เรียบร้อย และกำหนด Multiplicity ให้สมบูรณ์
(ย้ำ สมบูรณ์) ส่วน Navigability กำหนดให้เป็นแบบ Bi-Directional ชัวร์สุด กันเหนียว

จากนั้น Class Diagram นี้ก็ Map ไปเป็น Relational Data Model (ER Diagram) ต่ออีกที การ Map จากยากหน่อย
หากใน Object Data Model มีการใช้ความสัมพันธ์แบบ Generalization (การ Extend / Inheritance) เพราะ Table ใน
Relational Database มัน Extend / Inherit กันไม่ได้ ต้องใช้เทคนิคในการ Map หรือใช้พวก Architectural Patterns
มาช่วยในการ Map

การ Map ที่ว่าข้างต้นเรียกว่าการทำ Object-to-Relational Mapping (ORM)

ส่วนจะทำอะไรก่อนอะไรหลังระหว่างทำคลาสก่อน หรือ ทำ table ก่อน

ขึ้นกับ Software Development Process และที่สำคัญขึ้นกับการแบ่งทีมงาน (Resource) และความรู้ความชำนาญของผู้ทำ
เช่น

Case: 1
นาย ก เป็น Software Designer ออกแบบ Object Data Model เก่ง นาย ก ก็ทำไป ส่วนนาย ข ออกแบบ ER Diagram เก่ง
นาย ข ก็ทำไป สุดท้าย นาย ค เป็น Architect หรือ เป็นอะไรก็ได้แต่เก่ง ORM ก็มาทำการ Map งานนาย ก กับนาย ข

Case: 2
นาย ก เก่งไปหมด Solo คนเดียว ดังนั้นจะทำอะไรก่อนก็ได้ หรือทำไปพร้อม ๆ กันก็ได้ เช่น หาคลาสได้ 4 ตัว ก็ Map ไปเป็น
Table ก่อน จากนั้นอีก 4 วันหาคลาสได้อีก 5 ตัว ก็ Map ไปเป็น Table อีก

Case: 3
บริษัทของนาย ก, ข และ ค ใช้ Software Development Process คือ XP โดยมี Policy ว่าต้องออกแบบ Object Data Model
ก่อน แล้วค่อย Map ไปเป็น ER Diagram ดังนั้น นาย ก ต้องออกแบบ Object Data Model ก่อน เสร็จแล้วนาย ค
ก็ Map ไปเป็น ER Diagram โดยนาย ค มีนาย ข เป็นที่ปรึกษาด้าน RDBMS / Relational Database Design
* ซึงบริษัทใหญ่ ๆ นาย ข มักถูกแบ่งออกไปเป็น นาย ข-ไข่ ทำหน้าที่ออกแบบ ER Diagram และ นาย ข-ขวด ทำหน้าที่
เป็น DBA

Case: 4
บริษัทของนาย ก, ข และ ค มีประสบการณ์และชำนาญด้าน RDBMS และ/หรือ ไม่มี Software Development Process
ที่มีวุฒิภาวะ (Maturity) ที่ดี และ/หรือ DBA เป็นใหญ่หรือมี Power มาก (หลายองค์กรโอ๋ DBA มากเกินควร เพราะ Sensitive
กับข้อมูลใน 'ถัง' ข้อมูลมากเกินไป) และ/หรือ นาย ก ไม่ได้เก่งด้าน Object Data Model แท้จริง แต่มีรากเหง้าประสบการณ์
ความรู้ ความชำนาญ และทัศนคติด้านการออกแบบ ER Diagram มามาก (เข้าข่าย Database Driven Development)
อาจทำให้การออกแบบ Object Data Model ไม่ดีเท่าที่ควร Case นี้ นาย ข มักเป็นผู้เริ่มทำก่อน โดยออกแบบ ER Diagam
ก่อน แล้วนาย ก ค่อยมาดูแล้ว Map ไปเป็นคลาส แต่ด้วย นาย ก ไม่แม่นเรื่อง Object Data Model ทำให้อาจได้คลาส
แบบผิด ๆ หรือไม่ดีออกมาได้ หลายครั้งสำหรับ Case นี้มักพบว่านาย ก กับนาย ข เป็นคนคนเดียวกัน คือ นาย กข และมักออกแบบ
ER Diagram ก่อน โดยในหัวคิดอะไรก็เป็น Column, Record, Table, Primary Key, Compound Key, Foreign Key,
Constraint, One-to-One, One-to-Many, Many-to-Many ฯลฯ แล้วค่อยมาหาคลาส หลายครั้งพบว่า Object Data Model
ไม่ได้ทำ แต่ได้คลาสเลย พอต่อมามีปัญหาขึ้นมา จะ Trace กลับไปก็ลำบาก

ยังมี Case อื่น ๆ อีก แต่ 4 Case ข้างบนมักพบเห็นได้บ่อย ๆ Case ที่ดีคือจะทำอะไรก่อนก็ได้ระหว่าง Object Data Model
กับ ER Diagram แต่สำคัญไอ้เจ้าตรงกลางนี่ล่ะ คือการทำ Object-to-Relational Mapping ต้องมีคนทำเป็นจริง ๆ
Map เป็น คนที่ Map เก่งนอกจากต้องเก่ง OO, การออกแบบ Object Data Model และการออกแบบ ER Diagram แล้ว
ต้องเข้าใจเรื่อง Application / System Performance, Transaction, Persistence Mechanism, Resource
Comsumption ด้วย

ดังนั้นหากต้องการ Generate จากคลาสไปเป็น Table โดยใช้ Tool ต้องศึกษาว่า Tool นั้นใช้เทคนิคการ Map แบบไหน
สามารถให้เราปรับแต่งหรือกำหนดการ Map ได้หรือไม่ (Tool ส่วนมากให้ทำได้)

แต่ที่สำคัญคลาสที่จะถูก Generate ไปเป็น Table ต้องเป็น Entity Class เช่น เป็นพวก Value Object (JavaBeans)
ซึงคลาสเหล่านี้จะมี Persistence Mechanism / Logic ฝังอยู่ด้วยหรือไม่ก็ได้ ขึ้นกับเทคนิคการออกแบบ

ลองหาหนังสือชื่อ Patterns of Enterprise Application Architecture โดย Martin Fowler มาอ่านดูนะครับ
จะมี Architectural Patterns ที่น่าสนใจในการทำ Object-to-Relational Mapping รวมถึงการทำ Inheritance Mapping
ที่น่าสนใจหลายตัว และอ่านง่าย

- จงอย่าเชื่อ Tool เสมอไปว่ามันเลือกใช้กลยุทธ์ (Strategy) ที่ดีที่สุดในการทำ Mapping / Generate ให้กับเรา -

- ผลลัพธ์ของการออกแบบจะไม่แสดงให้เห็นทันทีที่ซอฟต์แวร์ถูกพัฒนาเสร็จ ดังนั้น Software Testing ควรถูกบรรจุ
ไว้ทุก ๆ ช่วงของกระบวนการพัฒนาซอฟต์แวร์ -

minimalist (ณรงค์ จันทร์สร้อย)
21 ธันวาคม 2549