iBatis Quick Start Tutorial

ใช้ iBatis แล้วดียังไง? iBatis เป็น Data Mepper Framework ที่เมื่อเราใช้มันแล้ว อย่างที่เห็นชัดๆกับตาเลยก็คือ มันช่วยให้เราทำ Operation ต่างๆกับ Database ได้ง่ายขึ้น เช่น

การ select ข้อมูลออกมาจาก Database

Person person = (Person)sqlMap.queryForObject(”getPerson”, 1);

ถ้าอยากจะ update ก็แค่นี้

person.setFirstName(”Jack Sparrow”);
sqlMap.update(”updatePerson”, person);

หรือถ้าต้องการลบก็ทำแบบนี้เท่านั้น

sqlMap.delete(”deletePerson”, person);

ซึ่งก่อนกที่เราจะทำอะไรได้อย่างที่บอกมา เราก็ต้อง configure ค่าๆต่างๆตามขั้นตอนที่จะว่าต่อไปนี้ก่อน


โดยการใช้ iBatis อย่างง่ายนั้น มีขั้นตอนหลักอย่างง่ายๆ 4 ขั้นตอน กับ 4 ไฟล์ที่จะมาเกี่ยวข้อง คือ

1. สร้าง class ในลักษณะของ JavaBean pattern
2. configure ข้อมูลต่างๆที่จะใช้ติดต่อกับ DBMS
3. กำหนด operation ต่างๆที่เราจะใช้งาน
4. เรียกใช้งาน operation ที่เราได้สร้างขึ้น

ก่อนอื่นสร้างตารางที่จะใช้งานใน Database ก่อน

CREATE TABLE PERSON(
     ID integer(5) NOT NULL,
     FIRST_NAME VARCHAR (40) NOT NULL,
     LAST_NAME VARCHAR (40) NOT NULL,
     BIRTH_DATE DATE ,
     WEIGHT decimal (4, 2) NOT NULL,
     HEIGHT decimal(4, 2) NOT NULL,
     PRIMARY KEY (ID)
)

หลังจากตารางพร้อม เราก็มาดูที่ขั้นแรกกันเลย

1. เราจะสร้าง class ชื่อ Person สำหรับใช้ส่งข้อมูลกันไปมา ในขณะที่เราทำ operation ต่างๆ หน้าตาแบบนี้

public class Person {

     private int id;

     private String firstName;

     private String lastName;

     private Date birthDate;

     private double weight;

     private double height;

… // อย่าลืม implement set/get method สำหรับ property แต่ละตัวด้วย

}

2. เมื่อ class ที่เราจะใช้พร้อมแล้ว ต่อไป  ก็คือ mapping ข้อมูลต่างๆที่จำเป็นต่อการเชื่อต่อกับ DBMS (ในที่นี้ใช้ MySQL) โดยสร้าง XML ไฟล์ขึ้นมา ในตัวอย่างนี้ใช้ชื่อว่า SQLMapConfig.xml
จากนั้นเขียนในส่วน proleg ของ xml ว่า

<?xml version=”1.0″ encoding=”UTF-8″ ?>
<!DOCTYPE sqlMapConfig
  PUBLIC “-//ibatis.apache.org//DTD SQL Map Config 2.0//EN”
  “http://ibatis.apache.org/dtd/sql-map-config-2.dtd”>

อย่าลืมประกาศ DOCTYPE ให้ถูกต้องด้วย

จากนั้นสร้าง root element ชื่อ sqlMapConfig และสร้าง element ชื่อ transactionManager ลงในเป็น child ของ sqlMapConfig เพื่อ configure ค่าต่างๆที่จำเป็นในการติดต่อกับ MySQL ในลักษณะนี้

<transactionManager type=”JDBC”>

   <dataSource type=”SIMPLE”>

   <property name=”JDBC.Driver” value=”com.mysql.jdbc.Driver”/>

   <property name=”JDBC.ConnectionURL” value=”jdbc:mysql://localhost:3306/ibatis”/>

   <property name=”JDBC.Username” value=”root”/>

   <property name=”JDBC.Password” value=”"/>

   </dataSource>

</transactionManager>
<!– กำหนด resource ไปที่ไฟล์ Person.xml ด้วย (จะอธิบายต่อไปว่าใช้ทำอะไร) –>

<sqlMap resource=”testibatis/Person.xml”/>

3. กำหนด operation ต่างๆที่เราจะเอามาใช้งาน โดยเราจะกำหนด operation ต่างๆไว้ในไฟล์ xml  ในที่นี้ให้ชื่อว่า Person.xml
เริ่มจากกำหนดส่วน prolog ของ xml ให้ถูกต้องแบบนี้

<?xml version=”1.0″?>
<!DOCTYPE sqlMap
  PUBLIC “-//ibatis.apache.org//DTD SQL Map 2.0//EN”
  “http://ibatis.apache.org/dtd/sql-map-2.dtd”>

สร้าง root element ชื่อ sqlMap พร้อมทั้งกำหนดค่าให้ attribute ชื่อ namespace ว่า Person แบบนี้

<sqlMap namespace=”Person”>

</sqlMap>

จากนี้เราก็กำหนด operation ต่างๆได้ตามชอบใจได้เลย เช่น operation สำหรับการ insert ข้อมูลลงใน Database เราจะใช้ tag ชื่อ insert ดังนั้นก็จะได้ว่า

<insert id=”insertPerson” parameterClass=”domain.Person”>
   INSERT INTO PERSON (id, first_name, last_name, birth_date, weight, height)
   VALUES (#id#, #firstName#, #lastName#, #birthDate#, #weight#, #height#)
</insert>

เราจะเห็นว่าค่าที่อยู่ระหว่าง <insert> นั้นจริงๆมันก็คือ SQL นั่นเอง เพียงแต่มีเรื่องของค่าที่เราจะส่งเข้ามาด้วยเท่านั้นเอง ซึ่งเราจะใช้ # ครอบตัวแปรนั้นๆไว้

เมื่อรู้อย่างนี้แล้ว ก็ทำแบบเดียวกันกับ operation อื่นๆ ก็คือ
ถ้าจะ select เราจะใช้ <select> ส่วนถ้าจะ update ก็ใช้ <update> และจะ delete ก็ใช้ <delete> นั่นเอง เช่นตัวอย่างต่อไปนี้

<select id=”getPerson” resultClass=”domain.Person”>
     SELECT
     ID as id,
     FIRST_NAME as firstName,
     LAST_NAME as lastName,
     BIRTH_DATE as birthDate,
     WEIGHT as weight,
     HEIGHT as height
     FROM PERSON
     WHERE ID = #id#
</select>

<update id=”updatePerson” parameterClass=”domain.Person”>
     UPDATE PERSON
     SET FIRST_NAME=#firstName#,
     LAST_NAME=#lastName#,
     WEIGHT=#weight#,
     HEIGHT=#height#
     WHERE ID=#id#
</update>

<delete id=”deletePerson” parameterClass=”domain.Person”>
     DELETE FROM PERSON
     WHERE ID=#id#
</delete>

สำหรับ tag ของ operation แบบต่างๆที่ว่ามาตอนแรกนั้น จะมี attribute ชื่อ parameterClass และ resultClass ติดอยู่ด้วย ซึ่งนั่นก็คือเป็นการบอกว่า เราจะส่ง object ของ class อะไรเข้าไป และมันะ return object ของ class ไหนออกมานั่นเอง ดังนั้นเราจำเป็นจะต้องกำหนด class ให้สอดคล้องกับข้อมูลที่เราใช้งานด้วย

4. ขั้นตอนสุดท้าย หลังจากที่เรา สร้าง Bean กำหนดค่าสำหรับติดต่อกับ Database และกำหนด operation ต่างๆเสร็จเรียบร้อยแล้ว จากนี้ก็ถึงขั้นตอนของการนำมาใช้งานล่ะ ซึ่งการใช้งานก็ตรงไปตรงมาแบบนี้ได้เลยครับ

ขั้นแรกเริ่มจากการสร้าง object ของ SqlMapClient ก่อน แบบนี้

String resource = “testibatis/SQLMapConfig.xml”;
Reader reader = Resources.getResourceAsReader(resource);
SqlMapClient sqlMap = SqlMapClientBuilder.buildSqlMapClient(reader);

เมื่อได้ object ของ SqlMapClient มาแล้ว ต่อไปนี้อะไรๆก็ง่ายแล้วครับ

เรามาลองใช้ operation ต่างๆที่ได้สร้างไว้กันเลย
เริ่มจากการทดสอบการใช้งาน insertPerson ที่เราได้กำหนดไว้ในไฟล์ Person.xml แบบนี้

Person p = new Person();
p.setId(100);
p.setFirstName(”Devy”);
p.setLastName(”Jones”);
p.setBirthDate(new Date());
p.setWeight(30.4);
p.setHeight(165.5);
sqlMap.insert(”insertPerson”, p);

ทดสอบการใช้งาน getPerson แบบนี้

Person person = (Person)sqlMap.queryForObject(”getPerson”, 1);

ถ้าจะ update ก็ทำกับ object ของ Person ที่เรามีแบบนี้ และสั่ง update

person.setFirstName(”Jack Sparrow”);
sqlMap.update(”updatePerson”, person);

ส่วนถ้าต้องการลบ object ของ Person ก็สั่งมันไปตรงๆแบบนี้ได้เลย

sqlMap.delete(”deletePerson”, person);

และสุดท้าย สำหรับไฟล์ SqlMapConfig.xml นั้นเรายัง configure อะไรได้มากกว่าที่ได้บอกไว้ก่อนหน้านี้ครับ เช่น

<settings
     cacheModelsEnabled=”true”
     enhancementEnabled=”true”
     lazyLoadingEnabled=”true”
     maxRequests=”32″
     maxSessions=”10″
     maxTransactions=”5″
     useStatementNamespaces=”false”
/>

สำหรับความสามารถอื่นๆของ iBatis นั้น ตามไปอ่านต่อได้ที่ http://ibatis.apache.org/

Related Link from Roti

How to Share files with VirtualBox

วันนี้ได้มี โอกาสลองเล่น VirtualBox อีกรอบ (รอบแรกเล่นเมื่อนานมาก) แต่ปัญหาก็ยังเหมือนเดิมคือ หลังจาก install Windows XP เสร็จแล้วไม่สามารถเข้างถึงไฟล์ใน Guest ได้เลยทันที และไม่สามารถ drag ไฟล์ไป-มา ระหว่าง Guest และ Host ได้เลยตรงๆ เช่นเดียวกับที่ VMware ทำได้อย่างง่ายๆ ไม่เป็นไร มันเป็นของฟรีต้องทำใจ คู่มือที่มากับ VirtualBox อ่านแล้วมึนเพราะยาวไป แต่ก็มีสั้นๆหลายที่ เช่น ที่นี่

ผมใช้ Host เป็น Mac OS X 10.5.6 และ Guest เป็น Windows XP Service Pack 3
สำหรับการแชร์ (share) โฟลเดอร์ (folder) ระหว่าง Host กับ Guest นั้น วิธีก็คือ

1. ติดตั้ง Guest Additions หลังจากที่ติดตั้ง Windows XP เสร็จแล้ว โดยไปเลือกที่ Menu -> Device -> Install Guest Addition… หลังจากติดตั้งเสร็จแล้ว ต้อง restart Guest (Windows XP) 1 รอบก่อน


2. สร้าง Share Folder โดยไปที่ Device -> Shared Folder จากนั้นกดปุ่ม Add (รูป folder มีเครื่องหมายบวก) ทางด้านขวา จากนั้นเลือก folder ที่ต้องการบนเครื่อง Mac ตั้งชื่อด้วย และจำชื่อนั้นไว้ให้ดีเพราะขั้นตอนที่ 3 เราจะใช้ชื่อนี้อีกรอบ

3. สร้าง Batch File ขึ้นมา 1 ไฟล์ ไม่ยาก โดยการสร้าง text file ขึ้นมา จากนั้นเขียนข้อความลงไปข้างในว่า

net use x: \\vboxsvr\ชื่อของโฟลเดอร์ที่เราตั้งไว้ในข้อ 2

(มี space ระหว่าง x: และ \\ ด้วย)

หลังจากสร้างเสร็จแล้วก็ Save ไว้ที่ที่เราจะเรียกใช้ได้ง่ายๆ และตั้งชื่อเป็นอะไรก็ได้ที่มีนามสกุลเป็น .bat เช่น Mount.bat เป็นต้น โดยวิธีใช้ก็คือให้ double click ที่ไฟล์นั้นจากนั้นไปเปิดดูที่ My Computer ของ Windows จะพบว่ามี Drive ชื่อ X ปรากฏออกมาแล้ว และเมื่อ browse ดูข้างในจะพบว่าเป็นที่ที่เราได้สั่งแชร์ (Share) ไว้ในข้อ 2 นั่นเอง

Related Link from Roti

Pack JAR files with Jar Bundler.app on Mac

ใน Windows มีโปรแกรมชื่อ Altova สำหรับ Validate XML แต่โชคไม่ดีไม่มี Altova for Mac

ผมจึงใช้โปรแกรมชื่อ Validator ช่วย แต่มัน Validate ได้แค่ XML ที่ถูกกำหนด Schema ด้วย DTD เท่านั้น แต่ไม่สามารถ Validate ให้ XML ที่ถูกกำหนด Schema ด้วย XMLSchema ได้ ทำได้อย่างมากก็แค่ verify ว่า well-form หรือเปล่า

สุดท้ายผมตัดสินใจเขียนโปรแกรมสำหรับ Validate XML ด้วย XMLSchema เอง โดยก่อนเขียนผมก็ google ก่อน 1 รอบ ปรากฏว่าไปเจอที่นี่ - Validating XML with a W3C XML Schema ผมก็เลยจัดแจงใช้ Groovy เขียนแล้วใช้ NetBeans สร้าง Swing มาครอบเป็น GUI อีกชั้นนึง

หลัง จากทำเสร็จแล้วสั่งให้ NetBeans Build JAR ไฟล์ให้ แต่ไฟล์ก็ยังกระจัดกระจาย ผมจึงใช้โปรแกรมชื่อ Jar Bundler เพื่อน pack ไฟล์ต่างๆให้เป็น .app ที่ Mac คุ้นเคยดี โดยโปรแกรมนี้อยู่ที่

/Developer/Applications/Utilities/

หลังจากกำหนด Main Class ในแท็บ Build Information และ add resource ต่างๆลงไปเสร็จแล้วสั่ง Create Application ได้ทันที

แล้ว เราจะได้ .app มา 1 ไฟล์ เมื่อทดลองรันก็รันและทำงานได้เป็นปกติ แต่แล้วปัญหาก็เกิด เมื่อเราย้ายไฟล์ต่างๆที่เราโยนใส่ไปใน Additions to Classpath (ช่องด้านล่างของรูปนี้) มันถูกเราย้ายไปที่อื่น เมื่อทดลองรันโปรแกรมอีกครั้งพบว่ามันฟ้องแบบนี้ Cannot launch Java application, Uncaught exception in main method

ปัญหาก็คือมันมองไม่เห็น library ที่เราเพิ่มเข้าไปให้มันตอนแรก

วิธี แก้ก็คือ ให้ click ขวาที่ .app ที่ถูกสร้างขึ้นมาจากการสั่ง Create Application จากนั้นเลือก Show Package Contents และย้าย library ต่างๆที่เราต้องใช้ไปวางไว้ที่

myApp.app/Contents/Resources/Java/

จากนั้นเข้าไปแก้ไขไฟล์ info.plist ในส่วนของ Root/Java/ClassPath โดยกำหนด path ให้ชี้ไปที่ JAR ต่างๆใน lib ที่เราพึ่ง copy ไปวาง ในลักษณะเดียวกันกับรูปด้านล่าง

จากนั้นเราก็จะสามารถรันโปรแกรม .app ที่ได้มาได้ปกติ

สุดท้ายนี้มีข้อเตือนใจนิดนึงตรงที่ว่า "อย่าใช้ Groovy เขียน Application เล็กๆร่วมกับ Java ถ้าไม่จำเป็น" เพราะไฟล์ที่ได้จะใหญ่ เนื่องจากต้องรวม groovy-all library เข้าไปด้วย

จากรูปจะเห็นว่าโปรแกรมเล็กๆแค่นี้แต่ไฟล์ใหญ่ถึง 3.2MB เลยทีเดียว!

Related Link from Roti

Video Macworld San Francisco 2009 Keynote Address

วีดีโอ (Video) บันทึกงาน Macworld San Francisco 2009 ที่มี Phil Schiller ที่มาแทน Steve Jobs บรรยายออกมาเร็วจริงๆ

สามารถ download ได้แบบ Download [ m4v format ] or iTunes ขนาดไฟล์ประมาณ 1.07GB
Related Link from Roti

On-Line Analytical Processing (OLAP)

OLAP มักจะมี UI ให้ในหลายๆรูปแบบ บางรูปแบบก็จะมี client เฉพาะของตัวเอง บางแบบก็จะมี plug-in ไปโยนลง excel ก็มีแล้วใช้ plug-in เป็นตัวเชื่อมต่อ อีกแบบหนึ่งก็คือทำ UI เป็นเว็บไปเลย แบบเว็บนี้ค่อนข้างเป็นที่นิยมSQL OLAP เป็นเครื่องมืออันหนึ่งที่จะทำให้เราเข้าไปดึงข้อมูลจาก data warehouses ได้เร็ว

บางคนอาจจะใช้ SQL OLAP ในการ generate report เองก็ได้ ทำให้การเขียนโปรแกรมทำได้ง่าในงานที่ซับซ้อนมากขึ้น ซึ่งสามารถอ่านเพิ่มเติมเกี่ยวกับวิธีใช้ SQL OLAP functions ได้ ที่นี่

จะว่าไปแล้ว OLAP มันก็ไม่ได้เกี่ยวอะไรกับ database มากนัก เพียงแต่ว่ามันเกิดมาคู่กับเครื่องมือ data warehouses ทำให้ส่วนใหญ่มันต้องรวมเข้ากับวิชา database ไปด้วย แต่ feature ส่วนใหญ่ของมันก็ไม่ใช่ความสามารถที่ถนัด เพราะว่า DBMS จะถนัดในเรื่องของการจัดการข้อมูลที่มีจำนวนมากๆ หรือ security เป็นต้น แต่ OLAP ไม่ได้เน้นตรงนั้น แต่จะไปเน้นในเรื่องของการวิเคราะห์ข้อมูล การแสดงข้อมูลเป็นกราฟ เป็นตาราง (เช่น ตารางแบบ cross pad) เป็นต้น ซึ่งบ่อยครั้งเราจะเห็น UI ของ OLAP คล้ายๆกับโปรแกรมพวก spreadsheet เลย

หน้าที่หลักๆของ OLAP คือสามารถดึงข้อมูลมาแสดงในมิติต่างๆได้ สามารถแสดงผลบนหน้าจอเป็นรูปแบบต่างๆได้ สามารถมองข้อมูลในรูปแบบทางสถิติต่างๆเช่น หา min, max, นับจำนวน และดูในแง่ของการจัดลำดับก็ได้ เป็นต้น

.

Common OLAP Features

feature ที่เห็นโดยทั่วๆไปของทุกๆตัวเลยก็คือ ช่วยให้เราสามารถดูข้อมูลได้ในหลายๆมิติ เช่นดูยอดขายตามประเภท ตามลูกค้าแต่ละคน เป็นต้น นอกจากนี้แล้วในแต่ละ dimension เรายังสามารถดูในระดับชั้นการสรุปที่ต่างๆกันเช่น ถ้าเรามองในแง่ของยอดขาย เราก็อาจจะมองเป็นรายตัว รายกลุ่ม ถ้าแง่ของลูกค้า ก็ดูเป็นรายคน รายอำเภอ จังหวัด หรือเชิงเวลาก็อาจจะเป็นรายวัน รายเดือน รายปี เป็นต้น อีกทั้งยังสามารถดูได้ในลักษณะของ interactive กับระบบได้เลย ซึ่งเป็นที่มาของตัว O (โอ) ที่มาจากคำว่า online

.

OLAP Architectures

แบ่งเป็นทั้งหมด 4 แบบด้วยกัน ได้แก่

1. Multi-Dimensional OLAP (MOLAP)

ปกติข้อมูลที่อยู่ใน MOLAP จะ เป็นข้อมูลที่ถูกดึงมาจาก data warehouse โดยในกรณีที่เราสร้างโครงสร้าง และสร้าง data cube ขึ้นมาแล้ว เวลาเราต้องการที่จะใช้งานมัน เราก็จะสั่งให้มันโหลดข้อมูลจาก warehouse เข้ามา แล้วข้อมูลก็จะถูกเก็บไว้ใน data cube จากนั้น client หรือ user ก็จะสามารถ วิเคราะห์ข้อมูลได้ เวลาที่ user จะวิเคราะห์นั้น user จะ interaction กับ MOLAP ตรงๆเลย โดยไม่ได้ไปยุ่งกับ data warehouse (มันจะเกี่ยวเฉพาะตอนโหลดข้อมูลมาตอนแรก)

ถ้าหากว่า 1 เดือนต่อไป user อยากจะวิเคราะห์ใหม่ user ก็จะสั่งให้ MOLAP ไปดึงข้อมูลมาจาก data warehouses ใหม่ แล้วค่อยวิเคราะห์ ทำให้ข้อมูลที่ MOLAP นั้นจะไม่อยู่ถาวร โดยจะอยู่ชั่วคราวเท่านั้น นี่คือธรรมชาติของ MOLAP Server

OLAP อื่นๆก็มักจะมี UI ให้ในหลายๆรูปแบบ บางรูปแบบก็จะมี client เฉพาะของตัวเอง หรือบางแบบก็จะมี plug-in ไปโยนลงโปรแกรมประยุกต์ เช่น MS Office Excel ที่มี plug-in เป็นตัวเชื่อมต่อ หรืออีกแบบหนึ่งก็คือทำ UI เป็นเว็บไปเลย ซึ่งแบบเว็บนี้ค่อนข้างเป็นที่นิยม

ข้อสำคัญของ MOLAP อย่างหนึ่งก็คือ ข้อมูลจะเก็บในโครงสร้างข้อมูลแบบ Matrix และเก็บข้อมูลไว้ที่ Server แต่การจัดการกับ Matrix คือมันจะจัดการกับข้อมูลจำนวนมากๆได้ (คล้ายๆกับ array 2 มิติ) มีความสามารถจัดการกับ sparse matrix (array ที่มีค่าเฉพาะบางช่อง) ได้เป็นอย่างดี

ส่วนใหญ่แล้ว บริษัท Software ที่ขายพวก MOLAP จะเป็น บริษัท Software เกี่ยวกับสถิติ โดยพวกบริษัทที่ทำ database product จะไม่ค่อยถนัดทางด้านนี้เท่าไรนัก (ไม่ค่อยเห็นทำออกมาขาย)

.

2. Relational OLAP (ROLAP)

ลักษณะก็จะคล้ายๆกับ MOLAP แต่จะต่างกันตรงที่ว่า ROLAP (R ย่อมาจาก Relational) หมายความว่าข้อมูลที่เก็บมันไม่ได้ถูกเก็บอยู่ในรูปของ Multi Dimensional Array แต่จะเก็บในรูปแบบของ relational table และมันก็ไม่ได้เก็บข้อมูลอยู่ใน Relational OLAP Server ด้วย เพราะตัว Server จะจำแต่โครงสร้าง ส่วนตัวข้อมูลนั้นจริงๆจะยังอยู่ใน Warehouse ซึ่งเมื่อไหร่ก็ตามที่ user ต้องการจะค้นหาข้อมูล ตัว Server ก็จะไปดึงข้อมูลจาก warehouses แล้วก็ค่อยตอบกลับ user ไป

ข้อดีก็คือ มันไม่ต้องห่วงเรื่องปริมาณข้อมูลที่มันต้องจัดการ เพราะว่ามันไม่ได้เก็บข้อมูลเยอะมากแค่ไหนก็รับไหว เพราะมันไมไ่ด้รับอะไรอยู่แล้ว

ข้อเสียคือ เวลาจะทำอะไรก็ต้องกลับไปหาที่ data source ซึ่ง software ที่เป็น ROLAP ส่วนใหญ่แล้วมักจะเป็น software จำพวก database product ที่จะทำแบบนี้ เพราะ db product มันถนัดแบบนี้อยู่แล้ว เวลาเค้าทำโปรแกรมออกมาก็ไม่ได้มีอะไรเท่าไหร่ แค่เป็นโปรแกรมมิ่ง interface ครอบไว้อีกชั้นหนึ่งก็เท่านั้นเอง ซึ่งโครงสร้างข้อมูลก็เก็บเป็น relational database และการประมวลผลก็จะช้ากว่าแบบแรก

อย่างไรก็ตามทั้ง MOLAP และ ROLAP นั้น ปัจจุบันแล้ว หลายๆ Product ก็สามารถทำได้ทั้ง 2 แบบในตัวเดียว แล้วแต่ว่าเราจะเลือก

.

3. Hybrid OLAP Architecture

เป็นการเอา 2 แบบแรก (ทั้ง MOLAP และ ROLAP) มาผสมกัน โดยการเก็บบางส่วน และประมวลผลเองบางส่วน

เก็บส่วนไหน? ปกติแล้วข้อมูลที่จะเก็บ ก็คือข้อมูลส่วนที่เป็น summary ส่วนใน warehouse ก็อาจจะเก็บข้อมูลแบบรายวัน เช่นถ้าเราเก็บ summary ของรายเดือนไว้ เวลา user ถามรายวันมันก็จะไปค้นจาก warehouses ส่วนถ้าถามรายเดือนก็อาจจะเอาคำตอบมาให้ได้เลยทันที

ข้อดีคือ ถ้าเก็บแต่ผลสรุป มันก็ไม่ต้องเก็บเยอะ ใช้ที่น้อย
ข้อเสียคือ ถ้าเค้าถามรายละเอียดมากๆเข้า มันก็ไม่มีตอบ ทำให้ยังไงก็ต้องไปค้นหาใน warehouse อยู่ดี

.

4. Desktop OLAP Architecture

เป็นการดึง cube จาก server มาเก็บไว้ที่ client เลย จากนั้นก็วิเคราะห์ด้วย desktop เอง ทำให้ไม่ต้องดึงข้อมูลส่งไปมาในลักษณะเดียวกับแบบต่างๆที่ได้กล่าวไป ทำให้ดูเหมือนว่าน่าจะทำงานได้เร็ว แต่ถ้าข้อมูลเยอะๆก็ต้องช้าอยู่ดี เพราะว่า desktop ไม่มีพลังมากพอสำหรับข้อมูลขนาดเยอะๆ

.

ที่มาของภาพประกอบ: เอกสารประกอบการบรรยายวิชา Database Technology โดย Kriengkrai Porkaew, Asst.Prof., Ph.D.

Related Link from Roti

9 Steps for Data Warehouse Design

หลังจากตอนที่แล้วที่บันทึกเกี่ยวกับ Data Warehouse Model ไปแล้ว คราวนี้จะมาบันทึกเกี่ยวกับ 9 ขั้นตอนในการออกแบบ และสร้าง Data Warehouse บ้าง (ถ้าจำไม่ผิด อ.บอกว่า นาย Ralph Kimball เป็นคนอธิบาย 9 ขั้นตอนนี้) ซึ่งไม่จำเป็นต้องสนใจอะไรมากนัก เพราะปกติแล้วเราจะทำขั้นตอนต่างๆพวกนี้เองอยู่แล้ว นี่เป็นแค่สรุปเฉยๆว่าปกติต้องทำอะไรบ้าง แต่่เรื่องที่เห็นว่าน่าสนใจและมีประเด็นก็คือเรื่องเกี่ยวกับ Slowly changing dimension

Nine-step Methodology

1. Choosing the process
   • เคยบอกไปแล้วว่าการออกแบบ data warehouse มันมีแบบ top-down และ bottom-up โดยขั้นตอนแรกนี้เราจะคิดถึงการเลืิอกโปรเซส ว่าเราจะทำ warehouse สำหรับงานอะไร
2. Choosing the grain
   • เลือกระดับความละเอียดของงาน ว่าเราจะดูไปถึงระดับรายวัน หรือเอาแค่สรุปมาเป็นเงินเดือนก็พอ ให้เราเลือกระดับความละเอียดที่คิดว่าเราสนใจ
3. Identifying and conforming the dimensions
   • คิดว่าเราจะทำในแง่มุมไหนบ้าง เช่นวิเคราะห์ในแง่มุมของลูกค้า พนักงานขาย หรือในมิติของตัวสินค้า
   • ในมิติที่แน่ๆมิติหนึ่งเลยที่มักจะมีตลอดใน data warehouse ก็คือมิติของเวลา
   • หา conform dimension ด้วย เราอาจจะต้องหา หรือต้องการเปรียบเทียบ เพื่อให้มันเทียบกันได้
4. Choosing the facts
   • คิดว่าเราจะมองในแง่ใหนใน fact เช่นจำนวนชิ้นที่ขาย ผลการเรียนของนักเรียน เช่นเกรดของนักเรียน (เกรดก็คงต้องเป็นตัวเลข) โดยสิ่งที่เราจะเลืิอกเอามาเป็น fact ได้มันจะต้องบวก ลบ คูณ หารกันได้ อะไรก็ตามที่เป็นตัวเลขแล้วเอามาทำกันแล้วมีความหมาย แต่ของบางอย่างเป็นตัวเลขแล้วเอามาบวก ลบ คูณ หารกันก็ไม่ได้มีความหมาย เช่นเบอร์เสื้อเป็นต้น
   • fact ก็ควรอยู่ในระดับ granularity เดียวกัน เช่นเรามีธุรกิจหลายๆอย่าง แล้วแต่ละอันก็มีการชำระเงินเป็นรายเดือน รายปี รายวันเป็นต้น ทำให้ช่วงเวลามันเข้ากันไม่ได้ ดังนั้น granularity ควรจะเป็นแบบเดียวกัน unit เดียวกัน ถึงจะอยู่ใน fact table เดียวกันได้ เพื่อไม่ให้การตีความผิดความหมาย
5. Storing pre-calculations in the fact table
   • เวลาเราจะเก็บ fact เราควรจะเก็บข้อมูลที่ถูกคำนวนมาแล้วเรียบร้อย ไม่ควรเก็บอะไรที่จะต้องไปคำนวณอีกรอบ เพราะถ้าเราไม่ได้คำนวณมาก่อนหน้านี้แล้ว เวลาเราจะ query มันก็จะเสียเวลามาก เนื่องจากเรื่องนี้จะเล่นกับข้อมูลจำนวนมาก
6. Rounding out the dimension tables
   • แจกแจง dimension table เช่น เราอยากจะวิเคราะห์อะไรเกี่ยวกับลูกค้า เช่น ชื่อว่าคนไหนชื่ออะไร หรือบางทีเราไม่อยากสรุปเป็นรายบุคคล เราอาจจะอยากสรุปเป็นรายจังหวัด หรืออาชีพว่ากลุ่มอาชีพนี้ซื้อของเรามากน้อยแค่ไหน
   • ขั้นนี้เป็นขั้นของการออกแบบในเชิงของ static มากกว่า
7. Choosing the duration of the database
   • กำหนดว่าเราจะเอาข้อมูลจาก database มาใส่ใน warehouse บ่อยแค่ไหน
   • ส่วนใหญ่แล้วเราจะเอาข้อมูลมากองๆรวมกันไว้ก่อน จากนั้นค่อยเอามาใส่ใน warehouse ทีหลัง
   • บางคนใช้เทคนิคของ replication server เช่น เวลามีเหตุเกิดอะไรขึ้นกับ database ปกติแบบ online transaction ของทั่วไป โดยเมื่อมี transaction เกิดขึ้นก็จะดึงข้อมูลมากองๆรวมกันไว้ก่อน เมือถึงเวลาก็เอาข้อมูลมาสรุปจากนั้นถึงจะดึงมาใส่ไว้ใน warehouse แต่กระบวนการในการทำตรงนี้เราต้องวิเคราะห์ว่าจะเอาข้อมูลมาถี่ขนาดไหน แล้วเวลาเราเอาข้อมูลมา เราต้องคิดในเชิงที่ว่า ข้อมูลมันควรที่จะถูกสร้างและสะสมไปได้เรื่อยๆ (incremental) ไม่ถูกลบทิ้ง หรือสร้างใหม่ ซึ่งการออกแบบให้เป็น incremental นั้นก็ต้องใช้ความสามารถมากเหมือนกัน เช่นใน database มันจะต้องมีอะไรซักอย่างหนึ่งมาบอกว่าอันนี้เอาไปแล้ว โดยมากจะดูจากเวลา แต่ว่าบางทีข้อมูลมันมีการ update ทับ ทำให้เราตรวจสอบได้ยาก ทำให้บางทีเวลาจะออกแบบเราก็ต้องกลับไปดูที่ database ของเราด้วย ว่า transaction มันทำงานยังไง แล้วการที่จะดึงมา มันจะสามารถรองรับการดึงมาได้อย่างถูกต้องสมบูรณ์หรือเปล่า แต่ยังไงก็แล้วแต่ ก็ไม่ได้หมายความว่าเราจะเอาทุกๆอย่างใน database มาใส่ใน data warehouses เพราะเราอาจไม่ได้สนใจทุกๆอย่าง เช่นรายละเอียดปลีกย่อยบางอย่าง
   • อย่าลืมว่าข้อมูลที่อยู่ใน warehouses มันโตเรื่อยๆไม่มีวันเต็ม เราควรที่จะ schedule ในเรื่องของการทำ archive ด้วย เราควรจะทยอยเอาออก เช่นข้อมูลรายละเอียดของเมื่อ 10 ปีก่อนอาจจะไม่มีความหมายแล้ว แต่ข้อมูลสรุปของเมื่อ 10 ปีก่อนอาจจะยังมีความหมายอยู่
8. Tracking slowly changing dimensions (SCD)
   • เรื่องมีอยู่ว่า เวลาเรามี fact table อยู่ ซึ่งเป็น fact ที่เก็บข้อมูลมาตั้งแต่อดีตแล้ว เช่นเดิม fact table บอกว่านาย ก. ลงทะเบียนเรียนวิชา INT641 แล้วมีตารางหนึ่งบอกว่า INT641 คือวิชา DBT แต่พอมีข้อมูลของคนใหม่เข้ามาลงทะเบียน INT641 มันก็ไม่ใช่ DBT โดยแต่รหัสวิชานี้มันถูกเปลี่ยนไปเป็นวิชาอื่นแล้ว ทีนี้เราจะรู้ได้ยังยังไงว่า 641 ไหนเป็นวิชาไหน เราจะเห็นได้ว่า 2 คนลงรหัสเดียวกัน แต่คนละวิชากัน แบบนี้เราถึงเรียกว่า fact table มันมีการเปลี่ยนแปลงได้ เราจะทำยังไงเพื่อไม่ให้การเปลี่ยนแปลงนี้กระทบกับแบบอื่นๆ ซึ่งก็ต้องดูด้วยว่าข้อมูลที่เปลี่ยนมันน่าสนใจแค่ไหน และมีผลกระทบกับส่วนอื่นๆแค่ไหน
   • ใน lecture มีแค่ 3 type หลักเท่านั้น แต่ใน wikipedia บอกว่ามีทั้งหมด 6 type ด้วยกัน
   • ถ้ามีโอกาสจะกลับมาเขียนถึงความแตกต่างระหว่างแต่ละ Type อีกรอบ
9. Deciding the query priorities and the query modes
   • ขั้นนี้จะออกไปทาง physical แล้ว
   • มองว่า query ที่มาส่วนใหญ่มักจะเป็น query ลักษณะไหน เราอาจจะมองไปว่าเราควรจะสร้าง index ใน column ไหน
   • ถ้าผู้บริหารชอบดูข้อมูลรายเดือน เราก็ทำรายเดือนไว้รอเลย อยากถามก็หาได้เลยไม่ต้องไปคำนวณอะไรบ่อยๆซ้ำๆ
   • ขั้นตอนนี้คงต้องดูจากสถิติเองว่าเราควรจะต้องเตรียมอะไรไว้ล่วงหน้า หรืออาจจะต้องถามผู้ใช้เอง

ตอนต่อไปจะว่าด้วยเรื่องของ On-Line Analytical Processing (OLAP)

Related Link from Roti

Data Warehouse Model

หลังจากที่ได้อธิบายเรื่องอื่นๆเกี่ยวกับ data warehouse ไปแล้ว ตอนนี้จะเป็นบันทึกเกี่ยวกับ model ของ data warehouse ว่ามันจะมีรูปร่างหน้าตาเป็นยังไง

ปกติแล้วการออกแบบ Data Warehouse จะประกอบไปด้วย 2 ส่วนหลักๆคือ

1. Fact Table คือความจริงที่เกิดขึ้นในระบบ ข้อมูลที่เก็บอาจจะเป็นการ summary ของอะไรบางอย่าง และเก็บ key ต่างๆไว้เพื่อ link ไปยัง dimension table ซึ่ง Fact Table อาจต้องเปลี่ยนแปลงอยู่เรื่อยๆ
2. Dimension Table คือสิ่งที่ใช้อธิบายความหมายในแต่ละ แง่มุม โดยปกติแล้ว dimension table จะไม่ได้รับการ normalize และส่วนใหญ่แล้วข้อมูลที่เก็บอยู่ข้างในมักจะไม่มีการเปลี่ยนแปลง

หลังจากดูรูปประกอบด้านล่างแล้วจะเห็นภาพเองว่า Fact Table และ Dimension Table มีลักษณะเป็นแบบไหน

เ

Data Warehouse Schemas

แบ่งออกเป็น 2 แบบหลักๆคือ

1. Star Schema - ปกติจะมี fact table อยู่ แล้วจะมี dimension table ต่างๆมาอธิบายในมุมมองต่างๆกัน
2. Snowflake Schema - ปกติ dimension table จะไม่ถูก normalize แต่ถ้าเรา normalize dimension table แล้วเราจะเรียกมันว่า Snowflake Schema

มีบางตำราบอกอีกว่า ถ้ามี dimension table บางอัน normalize และบางอันไม่ normalize ก็เรียกแบบนี้ว่าเป็น Star Flake Schema

โดย Model ของแต่ละแบบเป็นดังนี้

.

Star Schema

Snow Flake Schema

ทำไมถึงต้อง Normalize และทำไมถึงต้องไม่ Normalize?

ถ้าหากว่าไม่ Normalize แล้ว สมมติว่า ถ้าหากเราอยากจะดูเป็นรายภาค เราก็จะเอา table มา join กันตรงๆเลย ก็จะได้คำตอบแล้ว แต่ถ้าหากว่าเรา normalize ไป กว่าจะได้คำตอบเราจำเป็นต้อง join หลายๆ table กว่าจะได้ข้อมูลออกมา ทำให้ star schema นิยมกว่า เน่ืองจากเวลาจะรู้อะไรก็จะได้ผลอย่างรวดเร็ว แต่ข้อเสียที่พบก็คือ ข้อมูลมันก็จะซ้ำซ้อนเยอะ แต่ก็ไม่ใช่ประเด็นเนื่องจากเดิมทีแล้ว ปัญหาหนึ่งที่เรากลัวข้อมูลซ้ำซ้อนเยอะก็เนื่องจากเวลาจะอัพเดทข้อมูล เราต้องตามอัพเดทให้หมด ซึ่งอาจตามไปอัพเดทไม่หมดก็ได้ และอีกอย่างหนึ่ง เรามองว่า data warehouse มันไม่มีอัพเดทหรอก เราเพิ่มเข้าไปเรื่อยๆต่างหาก ถ้าถามว่าเปลืองที่มั้ย? ก็ไม่เป็นไร ถ้าจะให้ได้ผลลัพทธ์กลับออกมาเร็ว

เราจะไม่ออกแบบโดยวิธี normalization เพราะเป้าหมายของ normalization ก็คือว่าของอะไรก็ตาม มันควรถูกเก็บอยู่ที่เดียวเท่านั้น ไม่ให้ซ้ำซ้อน แต่ใน data warehouses เนื่องจากว่า transaction ส่วนใหญ่มันคือการ scan ข้อมูล เพื่อหาทางสถิติ บางทีเราเรียกการออกแบบของ data warehouses ว่าการ de-normalize

.

การออกแบบแบบ star schema เราก็จะมี table หนึ่ง table เรียกว่า Fact Table ซึ่ง table นี้จะประกอบด้วย attribute ซึ่งเป็น primary key ของ dimension table ต่างๆรอบตัวมัน และจะมี field ที่ไม่ใช่ key เรียกว่า measure

ใน data warehouses ปกติแล้วอาจจะไม่ได้มี fact table อยู่ table เดียว และไม่ได้มี measure attribute อยู่อันเดียว โดยการมี fact table หลายๆอันจะเรียกว่า Fact Constellation และ dimension ที่ใช้ร่วมกันระหว่าง fact เราจะเรียกว่า Conform Dimensions และการที่แต่ละ fact มี dimension ร่วมกันแบบนี้จะช่วยให้เราหาอะไรบางอย่างข้ามกันได้

ตอนต่อไปจะเป็นเรื่องเกี่ยวกับขั้นตอนการออกแบบ Data Warehouse ทั้ง 9 ขั้นตอนที่ Ralph Kimball (รู้จักกันดีในนามของ ’Guru’ of Data Warehousing ) ได้แนะนำเอาไว้

รูปประกอบจาก Wikipedia: Star Schema และ Snowflake Schema

ตอนต่อไปจะเป็นบันทึกเกี่ยวกับ 9 ขั้นตอนที่เรามักจะทำกันตอนสร้าง Data Warehouse

Related Link from Roti

อื่นๆเกี่ยวกับ Data Warehouse

ต่อจากตอนที่แล้วที่เป็นเรื่องเกี่ยวกับ Architecture ของ Data Warehouse และ component ต่างๆที่เราควรรู้จักไว้ ซึ่งส่วนที่สำคัญอีกส่วนหนึ่ง ที่จะนำข้อมูลเข้ามาเก็บไว้ใน Data Warehouse ก็คือ ETL Tools ซึ่ง ETL Tools เป็นสิ่งที่ทำให้เราไปดึงข้อมูลเข้ามาได้ง่ายๆ ซึ่งถ้าเราไม่มี ETL Tools เราก็คงต้องเขียน select … from… where… เพื่อดึงข้อมูลเข้ามาเก็บเองด้วยมือเปล่า หรือบางที source ก็อาจไม่ได้เป็น Database ทำให้เราเขียน SQL ไปดึงข้อมูลมาไม่ได้

ETL Tools มีความฉลาดที่จะรู้จักข้อมูลชนิดต่างๆ แต่ทั้งนี้ทั้งนั้นก็ขึ้นอยู่กับว่าเราซื้อ ETL Tools ของใคร โดยแต่ละยี่ห้อก็จะมีความสามารถต่างๆกันไป เช่น ถ้าเราซื้อ ETL Tools ของ Oracle แล้ว ETL Tools ตัวนั้นก็อาจเป็นไปได้ว่าจะติดต่อ และเข้ากันได้กับ Oracle ได้มากกว่า ETL Tools จากค่ายอื่นๆ เป็นต้น

-

Extract-Transform-Load Process

โดยทั่วไปแล้ว ETL Tools ทำอะไรบ้าง?

• Data Cleansing - เมื่อมีข้อมูลมาแล้ว เราจะต้องมีการตรวจสอบความถูกต้องของข้อมูล แล้วปรับให้มันดีขึ้น รวมทั้งกำจัดข้อมูลทีผิดพลาดไป (ก็แล้วแต่ราคา และยี่ห้อของ ETL Tools ไม่ใช่ว่าทุกๆตัวทำได้เหมือนๆกัน)
• Data Transformation - ข้อมูลบางอย่างที่เราได้มามันไม่ได้อยู่ในรูปแบบที่เราจะเอาไปวิเคราะห์ได้ ง่ายๆ เช่น เรามีข้อมูลของคน เช่นวันเดือนปีเกิด ของลูกค้า แล้วเวลาเราเอาไปวิเคราะห์เราไม่ได้เฉพาะเจาะจงเป็นวัน เราจะคำนวนเป็นช่วงอายุ เช่นวัยเด็ก ผู้ใหญ่ ชรา เป็นต้น ทำให้เราต้อง convert ก่อนว่าเป็นวัยไหน เป็นต้น แต่ว่ายังไงก็ตามบางทีเราไม่ได้ใช้ค่าจริงๆของมันหรอก เราจะใช้ค่าเชิงหมวดหมู่ของมันเป็นต้น ตรงนี้เป็นหน้าที่ของ data transformation ซึ่งถ้ามี ETL Tools ดีๆเราสามารถกำหนดเงื่อนไขในการแปลงให้ได้เลย
• Data Loading and Refreshing - กำหนด schedule ได้ว่าจะให้โหลดมาทุกๆกี่วัน หรือทุกๆเท่าไหร่ รวมทั้งยังสามารถกำหนด storage ปลายทางได้อีกด้วย

-

Data Warehouses

• multi-dimensional เก็บข้อมูลหลายๆ dimension ก็เช่น สรุปยอดขายตามสินค้าที่ขาย ตามเวลาที่ขาย ตามสาขาที่ขาย เป็นต้น
• multi-level ก็เช่นเราอยากรู้เป็นตัวๆ ว่าขายอะไรไปเท่าไหร่ หรืออาจจะอยากรู้เป็นกลุ่มๆก็ได้ว่าสินค้ากลุ่มนี้ขายได้เท่าไหร่ หรืออาจจะดูเป็นระดับสาขา ระดับภาค หรือระดับประเทศก็แล้วแต่ว่าจะเลืิอก level แบบไหนยังไง

-

Approach to Building Data Warehouse Systems

แบ่งเป็น 2 แนวทางใหญ่ๆคือ Top-Down และ Bottom-Up

• Top-Down เรามองว่าองค์กรของเราต้องการสร้าง data warehouse เราก็ออกแบบมาเป็นอันใหญ่เลย พอออกแบบเสร็จแล้ว แต่ละหน่วยงานอยากจะเอาไปวิเคราะห์ก็จะดึงจาก warehouses อันใหญ่ไปวิเคราะห์ เอาไปเก็บไว้กับตัวเอง เช่นฝ่ายขายดึงไปวิเคราะห์ เราเรียกตรงนี้ว่าเป็น Data Mart ของฝ่ายขาย แล้วเวลาจะเอาไปวิเคราะห์ก็จะมี OLAP ของฝ่ายขายเองเข้าไปดึงจาก warehouse แล้วก็ใช้ OLAP ของเค้าวิเคราะห์เอาเอง หรือเค้าอาจจะไม่สร้าง Data Mart แต่โหลดไปทำ OLAP เลยก็ได้เหมือนกัน การออกแบบในลักษณะนี้ก็อาจจะทำให้ warehouses หลักทำงานเหนื่อยเกินไป เพราะว่าใครๆจะใช้อะไรก็ต้องมาต่อตรงที่นี่ทุกที
  • การทำแบบนี้โอกาสประสบความสำเร็จ มันค่อนข้างต่ำ เพราะถ้าเราจะทำระบบใหญ่ๆ แล้วถ้าหากว่าเราไม่รู้ครบถ้วนทุกแง่มุม บางทีมันไม่เสร็จสักที หรือไม่ได้เริ่มซักที ทำตรงไหนก็ผิดไปหมด แต่ถ้าหากว่าเราทำได้ดี มันก็จะได้ผลลัพธ์ที่ดี เพราะเราออกแบบมาตั้งแต่แรกหมดแล้ว
• Bottom-Up คือเอาภาคย่อยๆของหลายๆอันมารวมกัน (เอา data mart หลายๆอันมารวมกัน) แต่ก็อาจจะมีปัญหาคือ แต่ละอันก็จะมีการออกแบบที่ต่างกันไป อาจจะใช้ระบบวิธีการสร้าง ID อะไรกันไม่เหมือนกัน รอบของการอัพเดทข้อมูลก็อาจะไม่ตรงกัน แต่ละคนคิดไม่เหมือนกัน ทำให้เวลาเอาไปสรุปก็อาจจะเกิดปัญหาอีกได้ ดังนั้นการที่เราออกแบบไว้หลายๆอันแล้วเอามารวมกันอาจจะยุ่ง ทำให้เราต้องปรับแก้อะไรบางอย่างก่อนเอามารวมกัน ทำให้การออกแบบแบบนี้ อาจจะไม่ใช่วิธีการที่ดีเท่าไหร่นัก

แต่ก็แล้วแต่ว่าใครจะใช้แบบไหน ขึ้นอยู่กับประสบการณ์ ซึ่งประสบการณ์ที่ว่านั้น รวมไปถึงประสบการณ์ทั้งการทำ data warehouses และประสบการณ์ทั้งทาง domain หรือเรื่องที่จะทำนั้นๆด้วย

ตอนต่อไปเราจะมาพูดถึงเรื่อง Data Warehouse Model และ Schema บ้าง

Related Link from Roti

Developing Requirement ตอนที่ 2

6. Some Techniques for Gathering and Analyzing Requirements

• observation สิ่งที่ได้มาคือ requirement ปัจจุบัน เห็นยังไงก็เอามาทำแบบนั้น
• interviewing เราจะได้ requirement เพิ่มเติมจาก need ใหม่ๆของ user ได้

แต่อย่างไรก็ตามไม่จำเป็นต้องใช้วิธีการเดียวใช้ทั้งสองแบบก็ได้

Gathering and Analyzing Requirement

• Brainstorming(meeting) แบบนี้ใช้กันมาก เอาคนที่เกี่ยวข้องโดยตรงมาคุย โดยอ้อมไม่เอา และ conflict ที่เกิดขึ้น ณ ตอนนั้นจะได้แก้ไขได้ในตอนนั้นเลย คำที่ใช้อย่างเป็นทางการสำหรับ brainstorming ก็คือ JAD
• Prototyping กรณีที่ requirement ไม่เคลียร์ หรือ user ไม่เข้าใจระบบเท่าไหร่ เราก็จะทำ model นั่นเอง ที่ basic ที่สุดก็จะใช้ กระดาษ+ดินสอวาดให้ดูเลย และสิ่งที่เกี่ยวข้องส่วนมาก(ที่ทำเป็น prototype) ก็คือ ทำ User Interface นั่นเอง การเก็บข้อมูลทางเทคนิคปกติ user ไม่ค่อยสนใจเท่าไรนัก
• Informal use case analysis ใช้ use-case ช่วยในการเก็บ requirement ด้วย
  • case ที่ว่านี้ให้เรามองประเด็นที่เราสนใจ หรือจะมองเป็น task หรือ function งานหลักๆก็ได้
  • ใช้ use case แทน context diagram
  • use case เป็น informal technique (จะมีหรือไม่มีในเอกสารก็ได้)
  • use case จะเริ่มจากเราต้องหาให้ได้ว่าใครเป็น user, actor และระบุให้ได้ว่า actor แต่ละคนเกี่ยวข้องกับระบบในมุมมองไหนบ้าง
    • เช่นระบบห้องสมุดก็จะมี case หลักๆคือ คืน ยืม ต่ออายุ และทำ catalog หนังสือ ส่วน actor ก็จะมีแค่ นักศึกษากับบรรณารักษ์เท่านั้น และบรรณารักจะยุ่งอยู่กับแค่ case ของการทำ catalog หนังสือเท่านั้น เนื่องจาก case อื่นๆแม้บรรณารักษ์จะมีส่วนเกี่ยวข้องก็จริง แต่ก็ไม่ได้เกี่ยวโดยตรง (ไม่ใช่คนกระทำเองตรงๆ เป็นแค่ helper เท่านั้น)

Documenting Requirements

• ถ้าเป็นไปได้ ควรใช้มาตรฐานขององค์กร อะไรที่องค์กรมีให้ใช้ตามองค์กร
• บันทึกกการเก็บ requirement เอกสารต่างๆ รายงารการประชุม details และของ requirement ต่างๆที่เรามี ก็เอามาเก็บไว้ในภาคผนวกด้วย

ตัวอย่าง. Interview Note (ตัวอย่าง ไม่จำเป็นต้องเหมือนกันทีเดียว)

เวลาไปสัมภาษณ์เราจะต้องทำ และบันทึกสิ่งต่างๆ เช่น

• เราไปสัมภาษณ์ใคร, contact person คือใคร
• ใส่ version ที่สัมภาษณ์ด้วย (บ่อยครั้งเราจะสัมภาษณ์มากกว่า 1 ครั้ง)
• หน่วยงานที่ไปสัมภาษณ์ทำอะไร
• มองระบบปัจจุบันที่เป็นอยู่ รายละเอียดย่อๆให้เข้าใจก่อน ทั้งทางด้าน hardware, software, network สถานภาพปัจจุบันต่างๆ
• อย่าไปกระดาษเปล่า ค้นหาจากเว็บ หาข้อมูลก่อนไป รู้เขา รู้เรา
• ปัญหาที่มีคืออะไร
• เค้าอยากเห็นอะไรในระบบงานใหม่เพิ่มเติมจากระบบงานเก่าที่มีอยู่
• เอกสารต่างๆที่มีที่เราได้มาจาก user

7. Types of Requirement Document

มี 2 ประเภท หลักๆ คือ

1. Requirement Definition เขียนแค่ 1-2 บรรทัด สั้นๆเป็น eye bird view สำหรับผู้บริหารระดับสูง มอง requirement หลักของ user คืออะไรบอก user อยากได้อะไรบ้าง ไม่ได้ลงรายละเอียดอะไรมากนัก
2. Requirement Specification อันนี้คือ requirement ที่เราต้องการในระดับที่เอาไปใช้ปฏิบัติงานได้

The Content of Requirement Documents - เนื้อหาใน requirement มีอะไร

• ปัญหามีอะไรบ้าง
• background เป็นอย่างไร?
• สภาพงาน และระบบเป็นอย่างไร?
• Functional Requirement
• Non-functional Requirement

• เวลาเขียน requirement จะต้องเขียนให้ชัดเจน ไม่อย่างนั้นเอามาวัดผลยาก (พยายามเขียนแต่ในสิ่งที่วัดผลได้เท่านั้น)
• requirement ถือว่าเป็นสัญญาที่เรารับปากว่าจะทำให้ user และเอาไว้ประเมินตอนหลังด้วย
• พยายามอย่าใส่เทคนิคลงไปใน requirement เพราะมันเป็นสัญญา user ต้องอ่านได้เข้าใจด้วย

8. Reviewing Requirement

หลังจากเก็บ requirement เสร็จแล้ว เราควรที่จะต้องมา review อีกครั้ง โดยดูจากเรื่องหลักๆต่อไปนี้

• ลงทุนพัฒนาคุ้มค่าหรือเปล่า
• ความสำคัญของปัญหา
• ใน requirement จะต้องเคลียร์ ใช้สัญลักษณ์ที่สอดคล้องกันตลอดทั้งเล่ม
• ไม่กำกวม อ่านแล้วชัดเจน เข้าใจง่าย วัดผลได้ตรงๆ
• logically - บอกแค่ logic ห้ามบอกว่าจะ implement อย่างไร ให้มองแต่ what เท่านั้น
• details ต้องเพียงพอ
• requirement ที่ได้จะต้อง implement ได้ด้วยทรัพยากร และ technology ที่มีอยู่ในมือ คือสามารถหาได้ ณ ตอนนั้น
• ไม่ over constraints ไม่มีเงื่อนไขบังคับเยอะ เพราะมันจะทำให้ยืดหยุ่นน้อย
• จัดเรียงดี และ user ทุกคนต้องเห็นชอบด้วย

ปกติแล้วเราจะ validate โดยดูว่าตรง need จริงของ user หรือเปล่า และ verify โดยดูว่าตรงตาม spec ที่กำหนดไว้หรือเปล่า

Poor Requirement Document
requirement แย่ๆเป็นอย่างไร?

• Unstructured Specifications - เขียนเป็บพรรณาโวหาร ดูยาก แก้ยาก ควรที่จะเขียนเป็นข้อๆแทนจะเข้าใจและอ่านได้ง่ายกว่า
• Noise - อะไรไม่ต้องการ ให้เอาออก อย่าให้มีมากเกินไป requirement ที่เกินความจำเป็นไม่ได้ช่วยแก้ปัญหาอะไรเลย
• Silence - สิ่งที่เราต้องการมันหายไป
• Over-Specification - เอา design (หรือ how) มาใส่
• Contradictions - มีอะไรที่ขัดแย้งกันเองในเอกสาร
• Ambiguity - กำกวม
• Forward References reference - ควรอ้างอิงจาก source เป็นหลัก
• Wishful Thinking - requirement ที่เป็นไปไม่ได้

9. Managing Changing Requirement

ถ้าทำ requirement เสร็จสิ้นแล้วภายหลัง user ต้องการเปลี่ยน requirement เราจะต้องคิดก่อน ว่าควรเปลี่ยนหรือไม่ ซึ่งถ้าหากว่าจะเปลี่ยน ก็อาจจะต้องต่อรองกับ user ด้วย โดยมองที่ cost เป็นหลัก (cost หลักๆก็คือ เวลา)
ปกติแล้ว Requirement จะเปลี่ยนก็เพราะ 3 อย่างหลักๆนี้

1. Business process เปลี่ยน
2. Technology เปลี่ยน
3. เรา (ทั้งคนเก็บ requirement และ user ที่ให้ requirement) ไม่เข้าใจงานดีพอตอนที่เราทำ requirement

อย่างไรก็ตามเราจะหลีกเลี่ยง requirement กระดื๊บ (creep) ห้ามเพิ่ม requirement เกินความจำเป็น ห้ามเพิ่มทีละนิดๆ วิธีการแก้ไขก็คือเขียน scope งานให้กระชับ และเสร็จสิ้นตั้งแต่ตอนแรก

10. Difficulties and Risks in Domain and Requirements Analysis

อุปสรรคของ requirement ที่ทำมา มักจะเกิดจากสิ่งต่อไปนี้

• ไม่เข้าใจเนื้องาน ทั้ง user และคนเก็บ
• requirement เปลี่ยนบ่อย (ถ้าเป็นแบบนี้ควรทำระบบแบบ incremental) ทำให้งานไม่เสร็จสักที
• เก็บ requirement ไม่ครบ (แบบนี้เจอบ่อยมาก)
• พยายามทำบางอย่างมากเกิน แม้มันจะไม่จำเป็นต้องทำ
• requirement ขัดแย้งกันเอง (หลายครั้งเราเก็บ requirement มาจากคนมากกว่า 1 คน ซึ่งแต่ละคนอาจให้ requirement ที่ขัดแย้งกันได้)
• ยากที่จะเข้าใจ requirement ที่ยาวๆ เป็นพรรณาโวหารได้ แก้โดยการเขียนประโยคสั้นๆก็พอ ให้เข้าใจได้ง่ายๆ

Related Link from Roti

Developing Requirement ตอนที่ 1

บันทึกนี้จะกล่าวถึงเรื่องของหลักการสร้างและพัฒนา (หรือเขียน) requirements ขึ้นมา ซึ่งจะบันทึกไว้ทั้งหมด 10 หัวข้อหลักๆที่เราควรทำตอนสร้าง requirement

• การเขียน requirement ถ้าเขียนไม่ครบ ไม่เคลียร์ ระบบไม่เคย success ดังนั้นเรื่องนี้จึงสำคัญมาก

1. Domain Analysis

• เราจำเป็นที่เราจะต้องเข้าใจ background ของ application และเข้าใจระบบเข้าใจ domain ก่อน
• ข้อดีก็คือ (”เร็ว ดี”)
  • Faster development เนื่องจากเราได้ขอบเขตจากคนที่รู้จริงเกี่ยวกับระบบ
  • Better System ถ้าดีตั้งแต่เริ่มต้นแล้ว โอกาสผิดพลาดก็จะน้อย การแก้ไขก็น้อยตาม
  • เพิ่มขยายต่อไปทำได้ง่าย เพราะเราเข้าใจระบบได้ดีแล้ว การคิดต่อ ทำต่อก็ง่ายตามไปด้วย

Domain Analysis Document

• มองในเรื่องของ domain name และ motivation (โดย motivation อย่าเขียนลอยๆ ควรมีข้อข้อมูลสนับสนุนด้วย บางครั้งเขียนแค่ว่า อดีตคืออะไร ปัจจุบันคืออะไร และอนาคตจะเป็นยังไง ก็พอ)
• domain หรือองค์กรอื่นที่เกี่ยวข้องคือที่ไหนบ้าง อย่างน้อยถ้าเราสร้างใหม่ต้องไม่ด้อยกว่าเค้า
• ดูความต้องการปัจจุบันว่ามีอะไรบ้าง
• เทคนิค, software, hardware จะใช้อะไรบ้าง
• คิดว่า data ต้องมีอะไรบ้าง และ data นั้นจะได้จากแหล่งไหน
• อย่าเขียนมากไป เพราะจะเสียเวลา และห้ามผิดพลาด ถ้าผิดพลาดแล้วต้องปรับแก้อีกยาว นั่นคือ สั้นๆ แต่สื่อความหมาย

2. The Starting Point for Software Projects

โดยรวมๆแล้วจุดกำเนิดของ Software จะเป็นไปดังรูป โดย A กับ B (การพัฒนาใหม่ตั้งแต่ต้น) จะเกิดขึ้นน้อยมาก ส่วน C กับ D (การปรับปรุงดูแลรักษา) จะเกิดขึ้นบ่อยๆ

3. Defining the Problem and the Scope

• ปัญหาก็คือ สิ่งที่เราอยากได้และสิ่งที่เราได้รับมันไม่ตรงกัน
• อย่าลืมว่า requirement เกิดจากปัญหา เราต้องเขียนปัญหาให้สั้นๆ กระชับ เข้าใจง่าย และสื่อความหมาย

Defining the Scope

• เมื่อมีปัญหาแล้ว ให้มากำหนด scope ต่อ
• เวลาเขียนกรอบงานต้อง clear ว่าต้องมีอะไรบ้าง เขียนให้ชัดเจน
• อะไรก็ตามที่กว้างไปก็ลดให้เล็กลง อะไรก็ตามที่เล็กเกินไป ก็เพิ่มขยายเข้าไป

4. What is a Requirement?

• statement ที่ไม่ชัดเจน จะไม่มีทางทำได้สำเร็จเลย
• ถ้ากำหนดกรอบได้ควรกำหนดกรอบด้วย (กำหนด constraint) ว่างตรงไหนเราทำได้หรือทำไม่ได้ บางอย่างมันอยู่ในกรอบ ต้องอยู่ในกรอบเท่านั้นถึงจะทำได้ เช่นให้มองว่าถ้ามันเป็บแบบนี้เราจะทำได้ เป็บแบบนี้เราจะไม่ทำ เราจะทำไม่ได้ ดังนั้นต้องเขียนconstraint ให้ชัด ว่างานใหม่นี้เกิดขึ้นได้แต่ว่าต้องมีข้อกำหนดแบบนี้นะ งานนี้ถึงจะทำได้จริง
• ต้องเข้าใจตรงกันทุกๆ partner สั้น และกระชับ

Requirement Engineering

• สิ่งที่เราต้องรู้ก็คือ ทำอย่างไร requirement ถึงจะทำออกมาได้กระชับ และตรงตามความต้องการของ user?
• เมื่อเขียน requirement เสร็จแล้ว ท้ายสุดเราต้อง validate เพื่อให้มั่นใจว่า requirement นั้นๆตรงตามที่ user ต้องการจริงๆ

5. Type of Requirement

• Function บอกว่าระบบจะทำอะไรบ้าง
• Non-Function จะอ้างอิงจาก PIECES (Performance, Information, Economic, Control/Security, Efficiency, Security)

Functional Requirement
ให้แยกออกเป็น 2 ส่วน คือ Data กับ Transformations

1. Data โดยให้พิจารณาว่าข้อมูลจะเข้ามาในระบบได้อย่างไร จะเก็บไว้ที่ไหน แล้วข้อมูลนั้นจะออกไปไหน เช่นระบบต้องสามารถรับข้อมูล xxx ได้ และระบบต้องออก report xxx ได้ เป็นต้น
2. Transformations ระบบนี้จะประมวลผลอะไรบ้าง เช่นระบบนี้ต้องประมวลผลดอกเบี้ยได้ ต้องทำแบบนั้นแบบนี้ได้ ซึ่งก็คือกระบวนการทั้งหมดเลย ซึ่งก็คือการ transform ให้ได้สิ่งที่ต้องการนั่นเอง และถ้าเป็นไปได้ให้มองในเรื่องของการ consequence, parallelism ระบบนี้ทำงานพร้อมๆกันได้กี่งาน กี่คนด้วย
3. exception handling ถ้ามีข้อผิดพลาดเกิดขึ้นแล้ว ให้ทำอะไรต่อ? มองหาว่าอะไรผิดปกติแล้วมีอะไรบ้าง แล้วเราจะแก้ไขอย่างไร?

Non-functional Requirements: Quality
คือ business framework ซึ่งก็คือเงื่อนไขบังคับนั่นเอง

• ปกติ non-function จะไม่ต่างกันเท่าไหร่ในแต่ละโปรเจ็ค จะต่างกันก็ตรงการ tune-up นิดหน่อยในเรื่องของตัวเลข
• เชิง SE จะมอง usability, efficiency, reliability, maintainability, reusability
• ให้มองที่ PIECES เป็นหลัก
• โดยทั่วๆไปก็หนีไม่พ้นเรื่องเกี่ยวกับ response time ดี throughput ดี เชื่อถือได้ พร้อมใช้เสมอ ระบบล้มแล้วต้องกลับมาใช้ใหม่ได้ maintain ง่าย reuse ง่าย ใช้ resource น้อย ใช้กับ user ได้พร้อมๆกันกี่คน รับโหลดได้มากแค่ไหน
• ในเรื่องของ capacity เราจะมองว่าระบบให้บริการ user ได้พร้อมๆกันกี่คน
• Security & Safety
• Training
• Interface เราจะมอง 3 ด้านคือ
  1. User Interface สำหรับ user
  2. Hardware
  3. Software

ความต่างระหว่าง requirement กับ scope งาน ต่างกันอย่างไร?
Scope งานจะบอกเป็น eye bird view ภาพกว้างว่าจะทำอะไรบ้าง แล้วเอาภาพกว้างมาเจาะลึก ซึ่งก็คือ requirement นั่นเอง ส่วน requirement จะบอกว่าต้องการอะไรเท่านั้น ไม่ได้บอกว่าเราจะทำมันอย่างไร

Related Link from Roti

Data Warehouse Architecture

หลังจากทำความรู้จักกับ Data Warehouse ไปแล้ว ตอนนี้เราจะทำความรู้จักกับ Architecture โดยรวมของ Data Warehouse กันบ้าง โดยเริ่มจากรูปภาพคร่าวๆดังนี้

ที่มาของภาพ: เอกสารประกอบการบรรยายวิชา Database Technology โดย Asst. Prof.,Dr. Kriengkrai Porkaew

ตรงกลางคือ Data Warehouse

เริ่มจากมี OLPT ทั่วๆไปจากหลายๆแหล่ง แหล่งไหนก็แล้วแต่ แล้วเราก็ดึงข้อมูลเหล่านั้นเข้ามาใส่ใน warehouse โดยกระบวนการที่เราใช้ดึงเข้ามา เราจะใช้ ETL Tools ในการ extract ข้อมูลเข้ามา ซึ่งบ่อยครั้งเราไม่ได้เอามันเข้ามาใส่ใน warehouse ทันที แต่เราจะเอาไปใส่ไว้ในที่พักข้อมูลไว้ก่อน เราเรียกว่า Staging Area หรือบางตำราเรียกว่า Operational Data Store หมายความว่ามันเป็นที่ที่เก็บ Operational Data เอาไว้ชั่วคราวก่อน ซึ่งเหตุผลว่าทำไมต้องเอามาใส่ไว้ในที่พักก่อน ส่วนหนึ่งก็คือข้อมูลที่เอาเข้ามาอาจต้องเอาไปทำการ clean ข้อมูลก่อน หรือบางทีเราไม่ได้เอารายละเอียดไปใส่ไว้ใน warehouse แต่ที่เราต้องการคือเราเอาข้อมูลเข้ามา summary ก่อนจากนั้นเราก็เอาผลที่ได้จากการ summary เข้าไปใส่ใน warehouse ซึ่งบางตำราบางเล่มอาจจะแยกว่า Operational Data Store กับ Staging Area เป็นคนละอย่างกัน แยกกันอยู่ แต่นั่นก็ไม่ใช่ประเด็น

การดึงข้อมูลจาก Operational ไปใส่ใน warehouse เราต้องคิดว่าข้อมูลทีเกิดขึ้นใน Operational Database มันจะเกิดขึ้นตลอดเวลา เช่นเราซื้อของเข้ามา ขายของออกไป มันก็จะเกิดขึ้นตลอดเวลา ทำให้เวลาดึงเข้ามาใน warehouses ก็ไม่ได้ดึงเข้ามาตลอดเวลา มันมักจะมีการ schedule ไว้ว่าให้เอาทุกๆเดือน ทุกๆสัปดาห์เป็นต้น ทีนี้ปัญหาก็มีอยู่ว่า เราจะรู้ได้ยังไงว่าข้อมูลไหนเอามาแล้ว และยังไม่ได้เอามา หรือเอามาแล้ว แต่ต่อมาข้อมูลนั้นมีการอัพเดทใหม่ ทีนี้จะทำยังไง? ซึ่งตรงนี้จะกล่าวถึงอีกทีในหัวข้อถัดๆไป

–

Technical Terms เกี่ยวกับ flow ต่างๆ

บางตำราเรียกข้อมูลที่ไหลเข้า data warehouses ว่า “in-flow” ส่วนข้อมูลที่มีการสรุปเป็นรายปี รายวัน หรืออะไรก็แล้วแต่เรียกว่า “up-flow” ส่วนข้อมูลอะไรก็ตามที่ถูกดึงมาแล้ว เราต้องการเก็บข้อมูลเกี่ยวกับข้อมูลไว้ เช่นมันมาจากแหล่งไหน สัมพันธ์กันยังไง เราจะเรียกว่า “meta-flow“

ใน data warehouses ข้อมูลจะไหลเข้ามาเรื่อยๆ สักวันก็จะไม่พอเก็บ ดังนั้นแล้วเราควรจะวางแผนเอาไว้ด้วยว่าข้อมูลไหนที่เก่าแล้วเราควรจะย้าย มันออก ซึ่งการย้ายออกหรือ backup เราเราจะเรียกว่า “down-flow” เช่นการทำ Archive ก็คือเรามีข้อมูลอยู่ไม่อยากจะใช้มันแล้ว แต่อยากเก็บมันไว้ ก็เลยเอาออกไปเก็บไว้อีกทีหนึ่ง

“out-flow” ไมไ่ด้แปลว่าเป็นการเอาข้อมูลออกไปจาก data warehouse แต่มันเป็นการเอาข้อมูลออกไปใช้ (แต่ข้อมูลยังอยู่ใน warehouse นะ) เช่น การดึงข้อมูลออกมาเพื่อเอาไปวิเคราะห์ และเอาไปทำเป็น Data Mart หรือเอาไปใช้ในเชิงของ OLAP หรือเอาไปใช้ในเชิงของการทำ Data Mining เป็นต้น

ที่ว่ามาก็คือ flow การไหลเวียนของข้อมูลนั่นเอง

–

SQL OLAP

บางทีการที่เราจะดึงข้อมูลออกจาก data warehouse เราต้องเขียน SQL query ที่กว่าจะดึงออกมาได้เราต้องเขียน SQL ที่สลับซับซ้อน ที่ต้องใช้หลายๆ query กว่าจะดึงออกมาได้ ทำให้ standard SQL ได้ปรับปรุงคำสั่ง SQL ให้มีความสามารถให้เหมือนกับการรวมเอา SQL หลายๆอันมารวมเข้าด้วยกันให้เป็นอันเดียว แล้วสั่งทีเดียวมันก็จะ summary หลายๆมิติให้เราเองได้เลย คำสั่ง SQL เหล่านั้นเรียกว่า “SQL OLAP“

อ่านรายละเอียดเกี่ยวกับ SQL OLAP functions ได้ ที่นี่

–

Data Warehouse Components

• ETL Tools - เครื่องมือที่ทำให้เราสามารถไปดึงข้อมูลมาได้ง่ายๆ
• Operational Data Store/ Data Staging Area - เอาไว้เก็บข้อมูลชั่วคราว ก่อนนำเข้าไปใน warehouses
• Data Warehouses - ข้อมูลจะถูกสรุปในมิติต่างๆ และมีการ de-normalize ซึ่งปกติเราจะไม่ normalize เพราะถ้าเรา normalize เวลาจะมาค้นมาทีนึงเราก็ต้องมา join ข้อมูลหลายๆตาราง ซึ่งถือว่าเป็นการเสียเวลา โดยเราจะมีวิธีในการ design แบบหนึ่ง เรียกว่า Star Schema
• Data mart - จริงๆมันก็คือ data warehouses นั่นแหละ แต่มันเป็น data warehouses ที่มีขนาดเล็ก หรือจะเรียกว่าเป็น sub set ของ data warehouse ก็ได้ เวลาเราพูดถึง data warehouse แล้วเราก็จะมองว่าองค์กรของเรามีหน่วยงานย่อยๆเป็นกองต่างๆ แต่ละกองไปทำคลังข้อมูลของตัวเองก็แล้วกัน แบบนี้เราเรียกว่าเป็น Data Mart โดยการที่ทำ Data Mart มันทำให้เราสร้าง warehouse โดยรวมได้ไม่ยากนัก เพราะว่าในองค์กรหนึ่งๆ ก็จะมีหลายๆเรื่องเต็มไปหมด เราจะเอาทุกๆเรื่องไปรวมกันอยู่ที่ศูนย์กลาง ทำให้เรา design ออกมาทั้งองค์กรให้มันสมบูรณ์แบบเลยทีเดียวมันก็ยาก ถ้ามองอีกนัยหนึ่งแล้ว มันก็เหมือนกับการออกแบบ application นี่แหละ ที่มีหลายๆงาน ซึ่งปกติเราจะออกแบบและเขียนโปรแกรมแค่ส่วนงานหนึ่ง เช่น ระบบลา ระบบซื้อขาย ระบบขาดงาน โดย Data Mart ก็จะใช้ concept นี้คือใครอยากใช้อะไรก็ไปทำของตัวเองก็แล้วกัน โดยทำระบบย่อยๆของตัวเอง ทำให้ scale เล็ก และทำได้ง่าย
• Metadata Repository - เก็บ meta data ของสิ่งต่างๆไว้

ตอนต่อไปจะเป็นบันทึกเกี่ยวกับเรื่องอื่นๆของ Data warehouse อีกนิด เกี่ยวกับ ETL Tools และ Approach ในการสร้าง Data Warehouse

Related Link from Roti

Using Jasper Report with Grails ตอนที่ 2

หลังจากตอนที่แล้ว Using Jasper Report with Grails ตอนที่ 1 เราก็ได้ไฟล์ .jrxml ที่ถูก compile เป็น .jasper 

เริ่มกันเลย

ตอนนี้ผมสร้าง Controller ดังนี้

• InvoiceController - สำหรับจัดการเรื่อง Invoice
• ReportController - สำหรับจัดการเรื่องการออก report โดยจะไปเรียกใช้ Service ที่เราสร้างขึ้นเพิ่ม

และผมสร้าง Service ขึ้นมาหนึ่งตัว สำหรับช่วยออกรายงาน (report) ชื่อ

• ReportService - สำหรับ generate (สร้าง) ไฟล์ PDF ให้เรา

เริ่มจากสร้าง ReportService ก่อน โดยมี concept ดังนี้

1. มี closure ที่รับที่อยู่ของ .jasper ไฟล์ และรับ parameter สำหรับใช้ในการ generate report เข้ามา
2. เตรียม object ของ DataSource ที่เราจะไปอ่านข้อมูลมาใส่ใน report
3. เตรียม object ของ JREExporter สำหรับทำหน้าที่ export ไฟล์
4. เตรียม object ของ ByteArrayOutputStream สำหรับพ่น byte ออกไป
5. เตรียม object ของ JasperPrint สำหรับ fill parameter ต่างๆลงไปก่อน export
6. กำหนดค่าต่างๆให้ object ในข้อ 2 จากนั้นสั่ง export ได้เลย เป็นอันเสร็จ

ตามขั้นตอนที่ได้กล่าวมานำมาเขียน closure ได้แบบนี้

def generateReport = {jasperFile, parameters -> // รับ jasper ไฟล์ และ parameter สำหรับ fill ลงใน report

// ต่อไปก็เตรียม object ต่างๆตามที่ได้กล่าวมา

JRBeanCollectionDataSource ds = new JRBeanCollectionDataSource(parameters.inputCollection);

InputStream input = jasperFile.openStream()

JRExporter exporter = new JRPdfExporter()
ByteArrayOutputStream byteArray = new ByteArrayOutputStream()
JasperPrint jasperPrint = JasperFillManager.fillReport(input, parameters,ds)

// กำหนดค่าต่างๆให้ exporter และสั่ง export

exporter.setParameter(JRExporterParameter.OUTPUT_STREAM, byteArray)
exporter.setParameter(JRExporterParameter.JASPER_PRINT, jasperPrint)
exporter.exportReport()

// เราจะได้ข้อมูลที่ export เสร็จแล้วอยู่ในตัวแปรชื่อ byteArray (ตามที่ได้ประกาศไว้ด้านบน และนำมาใส่เป็น parameter) จากนั้นส่งค่ากลับออกไปให้ caller

return byteArray

แน่นอนว่าเราจะทำดังที่กล่าวมาไม่ได้เลยถ้าไม่ได้ import class ต่างๆต่อไปนี้ (ขาดๆเกินๆนิดหน่อย ถ้าขาดก็ไปหาเอาเองนะ )

import java.sql.Timestamp
import java.util.HashMap

import net.sf.jasperreports.engine.JRException
import net.sf.jasperreports.engine.JRExporter
import net.sf.jasperreports.engine.JasperPrint
import net.sf.jasperreports.engine.JasperFillManager
import net.sf.jasperreports.engine.JRExporterParameter
import net.sf.jasperreports.engine.data.JRBeanCollectionDataSource

เท่านี้ก็เป็นอันเสร็จการสร้าง ReportService สำหรับช่วยสร้าง byteArray ให้เราแล้ว ต่อไปเราจะเอา byteArray ที่ได้ไปสร้างเป็นไฟล์ PDF จริงๆซักที

เดี๋ยวเราจะเข้าไปเขียน code ใน ReportController ให้ไปเรียก action ใน InvoiceController ให้ query รายการต่างๆมาให้ แล้วถึงจะส่งไปให้ ReportService ช่วยสร้างให้อีกทีนึง ดังนั้น ไปที่ InvoiceController ก่อน เพื่อสร้าง closure ที่ทำหน้าที่ query ข้อมูลจากฐานข้อมูล แล้วส่ง object กลับไปให้ ReportController

ใน InvoiceController เขียน closure ไว้แบบนี้

def getPrintableReport = {
return PrintableInvoice.findAll(”from PrintableInvoice as pi where pi.invoice.id = ${params.id}”)
}

เมื่อเรามี ReportService และ closure ที่ ReportController ต้องการเรียบร้อยแล้ว ต่อไปก็มาลุยที่ ReportController อย่างเดียวเลย โดยมี concept และขั้นตอนดังนี้

1. หา controller ที่เราจะเรียก closure แล้วมันจะ return object สำหรับ fill ลง report มาให้เรา ซึ่ง controller นั้นก็คือ Invoice Controller
2. เรียก action ของ InvoiceController เพื่อให้มันคาย object ออกมาให้เรา
3. บอกให้ ReportService generate byteArray ให้เรา
4. เอา byteArray ที่ได้ไปสร้างไฟล์ตามต้องการ

ดังนั้น action สำหรับ เรียกใช้งาน และสั่งให้ generate Report ใน ReportController เราจะเขียนได้ดังนี้

// หา controller ก่อน

ApplicationContext ctx = (ApplicationContext) session.getServletContext().getAttribute(GrailsApplicationAttributes.APPLICATION_CONTEXT);

def controller = ctx.getBean(”InvoiceController”);

// เรียก action เพื่อให้ได้ object สำหรับนำไป fill ลงใน report

def inputCollection = controller.getPrintableReport(params)
params.inputCollection = inputCollection

// หา .jasper ไฟล์ที่เราต้องการนำไปสร้าง report โดยไฟล์นี้เราจะวางไว้ใน $PROJECT_HOME/web-app/reports/

def reportFile = servletContext.getResource(”/report/blog_report.jasper”)

// สั่งให้สร้างไฟล์ได้เลย

createPdfFile(reportService.generateReport(reportFile,params).toByteArray(),”invoice”)

// จาก code ด้านบนจะเรียก closure ชื่อ createPdfFile ซึ่งเราจะสร้างมันไว้ใน ReportController ดังนี้

def createPdfFile = { contentBinary, fileName ->

// แบบนี้ไฟล์จะถูก save เก็บไว้ที่ $PROJECT_HOME

FileOutputStream fo = new FileOutputStream(new File(”${fileName}.pdf”))
fo.write(contentBinary)
fo.close()

// ถ้าอยากจะให้ไฟล์ส่งตรงไปหา user เลยก็ทำแบบนี้

response.setHeader(”Content-disposition”, “attachment; filename=” + fileName + “.pdf”);
response.contentType = “application/pdf”
response.outputStream << contentBinary
}

ก็เป็นอันจบกันแค่นี้…

เฮ้ย ยังไม่จบ - -” ใน ReportController ต้อง import เจ้าพวกนี้ด้วย

import org.springframework.context.ApplicationContext;
import org.codehaus.groovy.grails.web.servlet.GrailsApplicationAttributes

จากนั้นประกาศตัวแปรที่ถูก inject เข้ามาด้วยแบบนี้

ReportService reportService

จบจริงๆซะที

Related Link from Roti

Using Jasper Report with Grails ตอนที่ 1

ตอนแรกนี้จะ เป็นการสร้าง jasper file จาก iReport ตามปกติ ซึ่งถ้าหากว่าใช้ iReport เป็นบ้างแล้วก็ไม่จำเป็นต้องอ่านละเอียดมากก็ได้ ให้ข้ามไป Using Jasper Report with Grails ตอนที่ 2 ได้เลย

ขั้นตอนหลักๆโดยทั่วๆไป มีดังนี้

1. สร้างไฟล์ .jrxml แล้วทำให้เป็น .jasper
2. เขียน code ใน Grails (แน่นอนว่าเป็นภาษา Groovy) ให้ไปเรียก Jasper Report ช่วย generate ไฟล์ให้

มาเริ่มกันเลย

เริ่มจากสร้าง jasper ไฟล์ก่อน ซึ่งมี 2 ทางเลือกคือ เขียน xml สดๆ แล้ว compile เอง หรือจะใช้ iReport ช่วยก็ได้แล้วแต่สะดวก และเนื่องจากผมไม่เก่งพอ ดังนั้นขอใช้ iReport แล้วกัน

เริ่มจากการสร้าง jrxml ก่อน โดยไปที่ new report ตั้งชื่อไฟล์ และเลือกที่เก็บให้เรียบร้อย

จากนั้น click ปุ่มนี้ ที่ toolbar เพื่อสร้าง Datasource อันใหม่ จะเจอหน้าต่างนึงขึ้นมา Title ไว้ว่า Connections / Datasources จากนั้นเลือก new เพื่อสร้างใหม่ จะพบหน้าต่างสำหรับ เลือกชนิดของ Datasource (Select the datasource type) ให้เลือก JavaBeans set datasource (สำหรับจะสร้าง report จาก class file ของเรา) แต่ถ้าต้องการแบบอื่นๆก็เลือกอันอื่นไป เช่นเราจะสร้าง report จากการติดต่อ MySQL แล้วก็ query ข้อมูลออกมา fill ใน report ก็เลือก Database JDBC connection เป็นต้น ในที่นี่เลือก javaBeans set datasource จากนั้นกด next แล้วจะเจอหน้าต่างนี้

ตั้งชื่อเพราะๆ และ text field 2 ช่องที่เหลือก็ไม่ต้องกรอกอะไร ปล่อยๆว่างๆไว้ แล้วก็ไม่ต้อง Test เพราะว่า Test ยังไงก็ไม่ผ่าน จากนั้นกด Save เป็นอันจบขั้นตอนการสร้าง datasource แล้ว

จากนั้นกลับมาปิดหน้าต่างสำหรับสร้าง datasource ออกไป แล้วมากำหนด datasource ที่เราจะใช้ที่ toolbar เป็นอันที่เราสร้างแบบนี้

ต่อไปเราจะกำหนด class ต่างๆที่เราจะใช้ โดยไปกำหนดที่ Options ของ iReport ในส่วนของ Classpath และถ้าหากว่าเราต้องใช้ font บาง font ด้วย เช่น font ภาษาไทยสวยๆ ก็กำหนดลงไปใน class path นี้ได้เลย พร้อมทั้งไปกำหนดใน tab Fontpath ด้วยว่า font อยู่ใน path ไหน โดย class ต่างๆใน Grails นั้น เมื่อ source file ของเราถูก compile ไปแล้วจะไปเก็บไว้ที่

$HOME/.grails/เวอร์ชั้น/projects/ชื่อโปรเจค/classes

จากนั้นก็ pack ให้เป็น .jar ก้อนกลมๆ แล้วเอาไปเก็บไว้ที่ไหนซักที่ (ในที่นี้ใช้ชื่อว่า my.jar) แล้วก็กำหนด Classpath ให้ iReport ชี้ไปหา jar file นั้นได้เลย ตามรูป

จากนั้น click ขวาที่โปรเจค แล้วเลือก Edit Query ตามรูปด้านล่าง

จะมีหน้าต่างปรากฏออกมา จากนั้นเลืิอก tab ชื่อ JavaBean Datasource และกรอก Class name ที่เราต้องการอ่านค่า attribute ลงไป จากนั้นกดปุ่ม read attribute จะมี attribute ต่างๆปรากฏออกมา ให้เลืิอก attribute ที่ต้องการ กดปุ่ม Add selected field(s) เมื่อได้ attribute ต่างๆที่เราจะใช้แล้วกด ok ดังรูป

เมื่อเรามาดูที่ Report Inspector ใน node ชื่อ fields จะพบว่ามี attribute ต่างๆตามที่เราเลือกไว้แล้ว เสนอหน้ามาให้เราพร้อมใช้งาน

ต่อจากนี้ก็เริ่มสร้าง jrxml ได้เลย โดยการลาก field ไปแปะๆ ตาม style การสร้าง jasper ไฟล์จาก iReport ปกติ จากนั้นกด Preview ดูผลลัพธิ์ iReport จะสร้างไฟล์ .jasper มาให้ (ตอนที่ 2 เราจะใช้ไฟล์นี้แหละ) ไม่ต้องตกใจถ้าจะเห็นว่าไม่มีอะไรใน field ต่างๆที่เรากำหนดไป นอกจาก null เท่านั้น

แค่นี้ก็สร้าง .jasper พร้อมใช้ไว้เสร็จแล้ว ตอนต่อไปจะเอา jasper ไฟล์นี้ไปใช้กับ Grails ตอนนี้พอแค่นี้ก่อน

สำหรับปัญหาที่มักพบกันบ่อยๆคือเมื่อ generate ออกมาแล้วไฟล์ Report ที่เป็น PDF มันไม่แสดงภาษาไทย! สามารถแก้ไขได้โดย

1. หา font ที่สามารถใช้ได้ฟรีๆ มากำหนดไว้ใน classpath และ fontpath โดยสามารถกำหนดได้ใน Options ของ iReport ตามที่ได้กล่าวมาแล้วข้างต้น
2. ในแต่ละ field ที่เราลากไปแปะในส่วนของ Designer นั้นให้กำหนด Property ต่างๆดังนี้

• Pdf Font name เป็นชื่อของ font ที่เราต้องการ และ support ภาษาไทยด้วย ซึ่งก็ควรจะเป็น font ที่เราเลือกมาแล้วเอาไปกำหนดไว้ใน fontpath แล้ว (ถ้า iReport เจอ จะเห็นชื่อ font ของเราอยู่ใน combobox ให้เลือกได้เลย ถ้าไม่เจอก็ควรตรวจสอบดูใหม่ว่า path กำหนดถูกต้องหรือเปล่า)
• Pdf Embedded ให้ติ๊กถูกใน checkbox (เราจะฝัง font ลงไปกับไฟล์ด้วยเลย ถ้าไม่ต้องการฝังไปก็ไม่ต้องติ๊ก)
• Pdf Encoding ให้เลือกเป็น Identity-H (Unicode with horizontal writing)

Note: iReport เมื่อรันบน Mac OS X (10.5.5) แล้วตรง panel สำหรับกำหนด property ต่างๆของ object ที่นำมาวางบน form นั้น เราสามารถกำหนดค่าได้ แต่เราจะมองไม่เห็นว่าตอนนี้เรากำหนดค่าอะไรอยู่ ต้องเอา mouse ไป click ตรง field นั้นๆ 1 ทีถึงจะเห็น ซึ่งตอนนี้ผมยังหาทางแก้ไม่ได้ ทำอะไรไม่ได้นอกจากทำใจใช้มันต่อไป

Related Link from Roti

การใช้ HTML กับ RichUI Accordion - Grails Plugin

วันนี้ลองเล่น RichUI Plugin ซึ่งเป็น plugin ตัวหนึ่งของ Grails ที่รวมเอา Ajax Component หลายๆตัวไว้ด้วยกัน และมันทำให้เราสร้าง Rich User Interface ได้อย่างง่ายๆโดยไม่ต้องเขียน Javascript เลยซักตัว

หนึ่งในนั้นคือ Accordion พอได้ใช้แล้วพบว่าเราไม่สามารถใส่ tag HTML ระหว่าง tag AccordionItem ได้ (จริงๆมันก็ใส่ได้ แต่ผลลัพทธ์ที่ได้ออกมาคือ plain text) ถ้าหากว่าใช้ tag HTMl ได้คงดีไม่น้อย จากนั้นผมก็ค้นหาวิธีจึงไปเจอวิธีแก้ ที่นี่

วิธีแก้ก็ง่ายๆ โดยการเข้าไปแก้ไฟล์ชื่อ AccordionItemRenderer.groovy ซึ่งอยู่ที่

$PROJECT_HOME/plugins/richui-เวอร์ชั่น/src/groovy/de/andreasschmitt/richui/taglib/renderer

และมองหาคำสั่งหน้าตาแบบนี้ (อยู่ประมาณบรรทัดที่ 20)

builder.”div”(”class”: “bd”, “${body.call()}”)

จากนั้นเปลี่ยนเป็น

builder.”div”(”class”: “bd”){
builder.yieldUnescaped “${body.call()}”
}

เป็นอันเสร็จเรียบร้อย และทดลองใช้ HTML ใน body ของ tag AccordionItem ดู จะพบว่าใช้ HTML ได้แล้ว

Related Link from Roti

Data Warehouse

จากครั้งที่แล้ว ก็ได้มีการเขียนถึง Data Warehouse ไว้บ้าง ครั้งนี้จะเขียนรายละเอียดเกี่ยวกับ Data warehouse เพิ่มอีกสักนิด

ถ้าอยู่ในโลกของ Data Warehouses น้อยคนนักที่จะไม่เคยได้ยิน 2 ชื่อนี้: Bill Inmon และ Ralph Kimball

Data Warehouses คือ collection ของ data ที่เอาไว้ใช้สนับสนุนการตัดสินใจ โดย Data Warehouse ที่ว่านี้จะต้องเป็น:

• Subject Oriented ให้มองว่าปกติแล้วในระบบ Operation มันจะเป็น Application Oriented เช่น ระบบคลังสินค้า มันก็จะว่าด้วยเรื่องของการซื้อสินค้าเข้าคลัง ย้ายสินค้าออกคลัง, ส่วนระบบจัดซื้อก็จะว่าด้วยเรื่องที่ว่าเราจัดซื้ออะไรบ้าง แต่ว่าในแต่ละระบบมันก็จะมี data เฉพาะของมันเอง แต่ถ้าในเรื่องของ data warehouse แล้วเราจะไม่ได้มองเป็น application ใดๆแบบที่ได้กล่าวมา แต่เราจะมองว่า ข้อมูลที่เรามีอยู่แล้ว เราจะเอาไปวิเคราะห์เพื่ออะไร เช่นวิเคราะห์ผลกำไรขององค์กร เป็นต้น ดังนั้นข้อมูลที่จะอยู่ใน warehouses ของเรา มันจะต้องเป็นข้อมูลที่ดึงมาจาก application ต่างๆเอามารวมกัน ซึ่งถ้าเป็นแบบนั้นแล้ว เราจะไม่ออกแบบข้อมูลเป็น application oriented แต่เราจะออกแบบข้อมูลเป็น subject oriented ซึ่งคำว่า subject oriented ในที่นี้ก็คือว่า เป้าหมายของเราอยู่ที่ไหน เราก็จะออกแบบข้อมูลเพื่อไปตอบเป้าหมายของเราที่อยู่ตรงนั้น เราไม่ได้ออกแบบข้อมูลตาม application ในขณะที่ database ทั่วๆไปมันจะออกแบบโครงสร้างข้อมูลตาม application นั้นๆ และแน่นอนข้อมูลที่เราเอามาเก็บใน data warehouses ก็มักจะเป็นข้อมูลที่ถูกดึงมาจากหลายๆ application และเมื่อข้อมูลมาจากหลายๆแหล่ง ข้อมูลก็มักจะต้องมีความขัดแย้งกัน และข้อมูลที่ถูกดึงเข้ามาก็มักจะมีข้อมูลเกี่ยวกับเวลาเข้ามาเกี่ยวข้องด้วย (จริงๆข้อมูลจะมีเวลากำกับอยู่เสมอ) เนื่องจากเป็นการเก็บข้อมูลแบบพอกพูนเพิ่มขึ้นเรื่อยๆ ไม่ได้ลบทิ้งออกไป
• Non-Volatile Data เราจะไม่ได้ลบข้อมูลเก่าออกไป ดังนั้นข้อมูลมันจะไม่มีวันสูญหาย (โดย concept)

–

Data Warehouse VS Traditional Database

ในที่นี้ เราจะมองในเรื่องของลักษณะข้อมูล การโปรเซส ลักษณะการใช้งาน และการออกแบบ

Data warehouse

• Subject-Oriented
• เป็นข้อมูลที่เก็บสะสมไปเรื่อยๆ แต่โดยมากแล้ว ยังไม่ได้เก็บข้อมูลของปัจจุบันยัง ณ ตอนนั้นโดยทันที แต่จะรอจนกว่าจะถูกสั่งให้ดึงข้อมูลเข้ามา
• ข้อมูลเป็น static มีแต่ข้อมูลใหม่เพิ่มเข้ามา ข้อมูลเดิมไม่มีการเปลี่ยนแปลง
• Transaction จะเป็นแบบการดึงข้อมูลเป็นจำนวนมาก และเอามาวิเคราะห์แบบซับซ้อน และเรามักจะไม่รู้ว่าวันนี้เราจะวิเคราะห์อะไร (แล้วแต่ผู้บริหารว่าอยากจะรู้อะไร) เวลาจะวิเคราะห์แต่ละครั้ง ปกติมันก็ต้องไปยุ่งกับข้อมูลจำนวนมาก ทำให้เราพยายามหลีกเลี่ยงไม่ให้เกิดการ Join ตารางกัน และพยายามจะไม่ normalize มัน โดยสิ่งที่เราจะมองหลักๆคือ เราจะทำยังไงให้มันดึงข้อมูลออกมาได้ง่าย และเร็ว
• มีเพียงไม่กี่คนที่เข้ามาใช้ แต่ว่าแต่ละครั้งที่ใช้จะ take processing power จำนวนมาก

Traditional Database

• Application-Oriented
• ข้อมูลปัจจุบันในฐานข้อมูล จะเปลี่ยนแปลงเรื่อยๆ
• Transaction จะเป็นแบบสั้นๆ ง่ายๆ ซ้ำๆ และเกิดบ่อยๆโดยการอ่านไม่กี่ record ในฐานข้อมูล
• ปกติจะมีคนใช้เยอะ และกิน processing น้อย

เนื่องจาก 2 แบบที่กล่าวมานี้ จะเห็นว่าลักษณะการใช้งานแตกต่างกัน ทำให้เราต้อง configure database ต่างกัน รวมทั้งการออกแบบ database ก็จะต่างกันด้วย

–

Problem in Building Data Warehouses

ปัญหาที่เห็นชัดๆเลยก็คือในเรื่องของ Data homogenization: บางที เราเอาข้อมูลที่มีธรรมชาติต่างๆกัน จากหลายๆแหล่งมารวมกัน บางทีมันรวมกันลำบาก และเพื่อให้มันรวมกันได้ เราจำเป็นต้องตัดส่วนที่มันต่างกันออกไป ทำให้เราเสียความเป็นความเฉพาะเจาะจงของข้อมูลออกไป มันก็เลยเป็นปัญหาว่า ถ้าเราอยากจะวิเคราะห์ข้อมูลข้ามหลายๆเรื่อง บางทีทำให้เราต้องตัดรายละเอียดออกไปบ้าง เพื่อให้ข้อมูลสามารถเข้ากันได้ เช่นเราเอาข้อมูลจากหลายๆแหล่งมาลงในตารางเดียวกัน บางทีมันทำไม่ได้ เพราะ attribute มันไม่เหมือนกันจะลงตารางเดียวกันได้ไง ทำให้เราต้องตัดให้เหลืิอส่วนที่มันเหมือนกันเท่านั้น ถึงจะเอามาลงตารางเดียวกันได้

ตอนต่อไปจะว่าด้วย Components ต่างๆของ Data warehouse

Related Link from Roti

Object-Oriented Technology (OOT) - (2)

6. Software Engineering Projects

Software Engineering Project จะเกิดขึ้นได้จาก 3 แบบหลักๆคือ

1. ในเรื่องของการบำรุงรักษา การพัฒนาเพิ่ม เช่น
   • เรื่องของข้อบกพร่องต่างๆ
   • การเปลี่ยนแปลงทั่วไปที่มี เช่น OS เปลี่ยนเวอร์ชั่น
   • แบบเพิ่มขยาย ขอบเขตงานขยาย เพิ่ม function ใหม่ๆให้ user
   • การ re-engineering คือการปรับระบบให้ปัจจุบันทันสมัยตลอดเวลา
   • ทั้ง 4 หัวข้อที่ว่ามานี้ก็จะมา support ในเรื่องของงานเดิมนั่นเอง
2. สร้างแต่น้อย
   • เริ่มจากไม่มีอะไรเลย green field development ไม่มีอยู่เดิมเลย ก็ทำใหม่ จำเป็นก็ต้องทำ ถ้าไม่จำเป็นก็ไม่ต้องสร้างเองใหม่ ให้เลี่ยงซะ เพราะเราจะมั่นใจได้อย่างไรว่าตัวที่สร้างขึ้นมาใหม่มันจะดีกว่าการทำงานเดิม
3. สร้างใหม่ คล้ายๆกับแบบที่ 2 แต่ว่าเป็นการสร้างใหม่โดย based on component ที่มีอยู่เดิม เช่น
   • การใช้ framework จะบอกขั้นตอน step-by-step ของงาน โดยถ้าเราบอกว่าเราทำตาม framework นี้ เราก็จะรู้ว่าขั้นตอนควรเป็นอย่างไร ซึ่งจะบอกแต่ภาพกว้างเท่านั้น details ไม่ได้บอก
   • component based สร้างงานใหม่จากของเดิม เอาจิ๊กซอว์ที่มีอยู่เดิมมาใช้ เช่นเวลาเขียนโปรแกรมเราก็จะมีการ include library เข้ามาใช้ได้เลย ไม่ต้องเขียนโปรแกรมซ้ำ
   • component กับ module ต่างกันยังไง?
     • Component ให้เรามองเป็น general term เป็นกลุ่มๆที่ทำงานโดยไม่ผิดพลาด แล้ว component ที่สร้างจะต้องเป็นอิสระต่อกัน แล้วแต่ละ component ก็จะมีความสัมพันกันเท่าที่จำเป็น
     • module หรือ function งาน ซึ่งจริงๆก็คือ component เหมือนกัน แต่เราจะใช้ในเรื่องของ programming แทน
     • ดังนั้นในเรื่องของ module & component เราก็จะได้ในเรืองของการ reuse + reliable software
   • เราจะได้ในเรื่องของ การลดค่าใช้จ่าย ทำได้เร็วเพราะไม่ต้องเขียนเอง เชื่อถือได้ดีในระดับหนึ่ง หรือจริงๆก็หนีไม่พ้นเรื่องของ “ถูก เร็ว ดี” นั่นเอง

7. Activities Common to Software Projects

ปกติจะมี 9 อย่างที่เราจะทำกันดังนี้

1. ดูว่ามันควรค่าแก่การพัฒนาหรือเปล่า ดูจากอะไร? ดูจาก เวลา ต้นทุน ความเป็นไปได้
2. การวิเคราะห์
   • โดยเริ่มมองตั้งแต่กรอบงานก่อนอันเรกคือ domain คือการที่เราต้องเข้าใจเนื้อหางานก่อน
   • ระบุปัญหานั้นได้ว่าปัญหานั้นคืออะไร
   • ได้ปัญหาแล้วค่อยมาเก็บรวบรวมความต้องการ requirement
   • เมื่อได้ข้อมูลแล้วก็เอามาวิเคราะห์สิ่งที่ user ต้องการ
   • ได้ requirement spec และจำเป็นต้อแสดง diagram ในมุมมองของ user ให้ได้ด้วย
3. design เราจะใช้ technology
   • จะออกแบบอย่างไร ใช้ technology อะไรถึงจะทำให้ได้ตรงตามที่ user ต้องการได้ ตรงนี้เราจะใช้คำว่า “how” ทำยังไงให้ได้ตามที่ลูกค้าต้องการ
   • สถาปัตยกรรมแบบไหน centralize หรือ distributed และจะ interact กันอย่างไร
   • มองข้างใน ระดับ code
   • database design จะต้องเดินก่อน I/O design
4. Modeling สร้างแบบจำลองออกมาโดยใช้ diagram ต่างๆ
   • ถ้ามองในเรื่องของโครงสร้าง เราจะใช้ class diagram
   • ถ้าเกี่ยวกับพฤติกรรม เราจะมองว่ามัน interact กันอย่างไรบ้าง เดิมทีเราใช้ data flow ตอนนี้เราจะใช้ state diagram
   • use-case เราจะใช้ use-case diagram
5. programming ก็คือการสร้างตัว softwareขึ้นมา
6. Quality จะมีเรื่องของคุณภาพมาเกี่ยวข้อง เวลาสร้างขึ้นมาต้องทดสอบ เพื่อให้มั่นใจว่า software ทำงานได้ถูกต้องสอดคล้องกับความต้องการของ user ด้วย
   • verification ตรงกับ product right คือ ทำได้โดยการทำงานถูกต้อง
   • validation ตรงกับ right product คือ ทำได้ตรงตามที่ user ต้องการ
   • การ verify เราจะ verity ตาม spec
   • ทำไมเวลา validate แล้วก็ยังไม่ตรงตามที่ user ต้องการอีก? อาจจะเพราะงาน delay เมื่องานช้า requirement ก็จะเปลี่ยน
   • Testing
     • Testing ควรทำก่อน, review, walkthrough ควรทำเป็นระยะๆ
     • เมื่อ test จากโปรแกรมเมอร์ผ่านเสร็จหมดแล้ว ให้ user ทดสอบต่อ
     • alpha test คือ test ในเครื่องทดสอบนั่นเอง คือใน development side
     • beta คือ test ที่ user side ปล่อยให้ user เทสโดยข้อมูลนั้นจริงทั้งหมด เราต้องการในเรื่องของสภาพแวดล้อมการทำงานจริง
     • regression test คือ การที่เราปรับแก้อะไรก็ตามในตัว software ต้องมั่นใจว่าประสิทธิภาพของเดิมก็ยังทำงานได้ แบบนี้เราจะเอาเทสทั้งหมดในอดีตมาทดสอบอีกครั้งหนึ่ง ของเก่าก็ยังทำงานได้ ของใหม่ก็ทำงานได้ไม่มี side effect แต่ส่วนใหญ่เราไม่ค่อยทำเท่าไหร่ ซึ่งแบบนี้จะเหมาะกับงานที่วิกฤติมากกกว่า ที่เราจะทำให้ง่ายกว่านี้นิดนึงก็คือเราทำ test cast ไว้ แล้วก็รันทีเดียวเทสจบ
7. Deployments คือการนำไปใช้ มีการ install, train เป็นต้น
8. Management software configuration คือการเปลี่ยนแปลงตัวระบบ เครื่องเปลี่ยน configuration ระบบเปลี่ยน เวลาเราดูเรื่อง change management เราจะมองคู่ไปกับข้อนี้
9. Managing the process

การสร้าง software เหมือนสร้างบ้าน เราไม่สร้างด้านบนก่อน ต้องเริ่มจากฐาน เราจะต้องรู้ mile stone ให้ชัดเจน และ monitor งานได้ ว่าเมื่อไหร่ ตอนไหนได้อะไร และทำอะไรบ้าง

8. The Themes of OO Study: to build good IS

มี 9 ข้อ ให้เรามองเป็น best practice ได้เลย

1. เข้าใจ user และ ลูกค้า รู้ว่าเค้ามีปัญหาอะไร (รู้เขา)
2. เรารู้หลักมั้ย? Reuse technology และเราต้องเข้าใจใน OO (รู้เรา)
3. รู้และเข้าใจ OO concept เป็นอย่างดี
4. รู้วิธีการที่เราจะสร้างมันขึ้นมา รู้จัการใช้ UML ให้เป็น
5. รู้ทางหนีทีไล่ต่างๆเป็นอย่างดี
6. มองเรื่องของตรรกะได้ ว่า user ต้องการอะไรเป็นยังไงได้
7. agile development ไม่มีงานไหนที่จะทำครั้งเดียวแล้วมันจะแล้วเสร็จ
8. ต้องมีการ communicate ที่ดี การ communicate นี้ไม่ใช่คำพูดนะ ต้องใช้ documentation
9. จัดการกับความเสี่ยง

ข้อ 4-8 คือการรู้วิธีการ

ทีนี้เราเอา 9 หัวข้อที่ว่ามา เอามาแปะกับ 4+1 framework ของเราจะได้แบบรูปนี้

9. Difficulties and Risks in Software Engineering

เมื่อได้ base practice แล้วเราลองมาดูเรื่องของความยากดูบ้าง

• ซับซ้อน
• ความไม่แน่นอนในเรื่องของ technology, requirement, skill
• software design มีการปรับเปลี่ยนแก้ไขไปหลายครั้ง
• การเมือง! แก้ไขยังไง?
• เอกสารต้องมี เปิดเผย โปร่งใส งบประมาณในการสร้างเท่าไหร่? คำถามนี้มักไม่มีใครตอบได้เมื่อเราถาม ผู้ใหญ่ห้ามบอก เพราะจะคอรับชั่น ดังนั้นวิธีการแก้ก็คือเราจะเอา bast practice มาแก้ ลองเอามาใส่ใน 4+1 framework ดู ปัญหาที่เกิดมากที่สุดก็จะเกิดที่ stakeholders ส่วนทาง IT นั้นก็จะเกี่ยวกับ skill, technology เปลี่ยนแปลง หรือไม่แน่นอน ตามรูปเลย

Related Link from Roti

Business Intelligence Tools - Overviews

Lecture note เรื่อง Business Intelligence Tools (Note นี้จะเน้นในเรื่องของ Data Warehouse เป็นหลัก)

เมื่อโลกของ XML มันขยายมากขึ้นทุกที

SQL 1999 เป็นเวอร์ชันที่ support เรื่องเกี่ยวกับ Object Relational ซึ่งก็คือการเอา Object ใส่ลงไปใน Relation Database แต่จนถึงตอนนี้ก็ไม่ค่อยมีคนนิยมใช้กันเท่าไหร่

SQL 2003 และ 2006 ก็จะเพิ่มตัวหลักๆขึ้นมา ซึ่งก็คือ XML ซึ่งก็หมายความว่าเดิมที RDB ในตอนที่เป็น Object Relational นั้น user ก็จะสามารถ define data type เองได้ แต่พอมาเป็น SQL 2003 และ 2006 เราจะพบว่า column ก็สามารถเก็บเป็น XML ได้ โดยจริงๆแล้วจะบอกว่า XML นี่ถือว่าเป็น object data type นึงก็ได้เหมือนกัน แต่ว่าปัจจุบันมันก็มี standard เกี่ยวกับ XML อยู่เยอะแยะให้ใช้อยู่แล้ว จึงสร้าง XML ขึ้นมาเป็น data type ใหม่ขึ้นมาอีกอันนึงเลย แทนที่จะบอกว่า XML เป็น object

XML จะเหมาะกับข้อมูลที่บางทีโครงสร้างมันมีความแตกต่างกัน แต่มันก็สามารถเอามาอยู่รวมกันได้

เนื่องจาก SQL/XML มันเป็น standard ใน SQL 2003, 2006 ซึ่งกลุ่มคนที่มาร่วมกันร่าง standard ก็จะเป็น บ. ยักษ์ใหญ่ทั้งนั้นแหละ ดังนั้นแล้วทุกๆ product ในที่สุดก็ต้องมาปฏิบัติตาม standard ตัวนี้ แต่ว่าในตอนนี้ Oracle ยังไม่ได้เป็นไปตาม standard ตัวนี้ซะทีเดียว อาจจะเพราะว่า Oracle ทำมาก่อนแล้วพอ standard มันออกมาก็เลยต้องใช้เวลาปรับตัวสักหน่อย แต่ว่า DB2 ของ IBM นั้นสนับสนุน standard นี้เรียบร้อยแล้ว

SQL OLAB ยู่ใน Standard 1999…

ก่อนจะไปเรื่อง SQL และ XML ก็มาเข้าเรื่องของ Business Intelligence Tools ก่อนดีกว่า เดี๋ยวจะนอกเรื่องไปมากกว่านี้

Business Intelligence Tools คืออะไร?

การทำธุรกิจในปัจจุบันล้วนแล้วแต่ต้องมีระบบ IT เข้าไปเกี่ยวข้องเสมอ ซึ่งตั้งแต่อดีดมา เราใช้คอมพิวเตอร์เพื่อใช้พิมพ์ว่าเกิดอะไรขึ้นและเราได้ทำอะไร จากนั้นก็แค่บันทึกไว้เท่านั้นเอง แต่การตัดสินใจว่าเราจะทำอะไรต่อไป ลงทุนอะไรต่อไป เรามักจะไม่ได้ใช้ระบบ IT เข้ามาช่วยคิด ต่อมาเราจะใช้ระบบ IT เข้ามาช่วยคิด ช่วยตัดสินใจ และนี่คือที่มาของเครื่องมือที่จะช่วยให้เราทำธุรกิจอย่างชาญฉลาด เพื่อให้ได้ผลตอบแทนที่ดีขึ้น และเราควรจะมี tools เข้ามาช่วยงานนั้นๆ ซึ่งมันก็จะประกอบไปด้วยหลายๆส่วนด้วยกัน เช่น

• Data Warehouses เป็นเพียงที่ที่เราจะเอาข้อมูลจาก database หรือเรียกสั้นๆว่า OLPT (เป็นลักษณะงานที่เราใช้ทั่วๆไป เป็น operator ทั่วๆไป เช่นซื้อของ ขายของ ทั่วๆไปในร้าน) ซึ่งเวลาเรามีข้อมูลเยอะๆเข้า แล้วเราก็อยากจะเอามาวิเคราะห์ โดยขั้นตอนแรกก็คือเอามันมาใส่ใน data warehouses ก่อน ต่อมาเราก็จะเอามันมาวิเคราะห์ โดยใช้เครื่องมืออย่าง OLAP Tools เป็นต้น
  • จริงๆ Data warehouses ก็ไม่ต่างอะไรกับ database หรอก มันเป็นแค่ที่เก็บข้อมูลเอาไว้เฉยๆ ซึ่งมันก็คือ software product ตัวเดียวกันกับ Database ทั่วๆไปนั่นแหละ เช่นเราซื้อ DB2 มา แล้วก็ configure ให้มันเหมาะกับการใช้ งานแบบ OLPT มันก็เป็น OLPT แต่ถ้าเรา configure ให้เหมาะกับ Data warehouses มันก็เป็น data warehouses ดังนั้นมันขึ้นอยู่กับเราจะออกแบบมัน ว่าจะให้มันใช้งานเพื่ออะไร ดังนั้น OLPT กับ Data warehouses จะเป็นอะไรก็ได้นั้น ขึ้นอยู่กับการ configure กับการออกแบบของเราเอง
• OLAP Tools จริงๆแล้วมันคือเครื่องมือในการทำ data analysis เพื่อเอาข้อมูลมาแสดงเป็น graph หรือเป็นตารางในรูปแบบต่างๆ เพื่อที่จะเอามาดูแบบ online และที่เรียกว่าแบบ online ก็เพราะผู้ใช้จะเปรียบเทียบกับในอดีตที่ว่าเวลาผู้บริหารอยากจะดูข้อมูลที่อยู่ ในระบบ ผบริหารก็ไปสั่งฝ่าย IT ให้ทำรายงานให้ ผู้บริหารดู ซึ่งอาจจะใช้เวลานานกว่าจะได้ และบางที ผู้บริหารอาจจะมีความต้องการที่ค่อนข้างเปลี่ยนไปเรื่อยๆ ทำให้เวลาต้องการอะไรทีนึงก็ต้องไปบอกฝ่าย IT ทีนึง ดังนั้นกว่าที่ ผบ. จะได้ข้อมูลออกมา มันก็จะเสียเวลา แต่ว่าบางทีเราทำโปรแกรมออกมาแล้ว มันก็สามารถเอามาใช้ต่อได้เรื่อยๆก็จริง แต่ว่ามันก็ยังมีการทำงานแบบ batch อยู่ ทำให้เมื่อต้องการทีนึง มันก็ยังนานอยู่ดี ส่วนแบบ OLAP มันเป็นแบบ online ที่สามารถทำให้เห็นได้เลยเดี๋ยวนั้น ช่วยให้ผู้บริหารสามารถดูได้ในมิติต่างๆเองได้ง่ายขึ้น
  • ปกติตัว OLAP Tools จะถูกขายโดยคนอีกกลุ่มหนึ่งที่ไม่ใช่คนกลุ่ม Database (ETL Tools, Data warehouses มักจะทำโดยพวก บ. ทำ Database ) แต่มักจะถูกทำโดยคนที่เชี่ยวชาญทางด้านสถิติ หรือกลุ่มคนที่มีความเชี่ยวชาญทางด้านวิเคราะห์ข้อมูล
• ETL Tools เดี๋ยวนี้หลายๆบริษัทก็จะขายแยกต่างหาก โดยมันมาจากคำว่า Extract Transform Load Tools คือ โปรแกรมที่ใช้ในการดึงข้อมูลจากแหล่งข้อมูล (เช่นไฟล์ หรือ database) ต่างๆเข้ามาใส่ใน Data Warehouses โดยตอนแรกๆ ETL Tools มันก็มากับ database นั่นแหละ แต่ต่อมาผู้ขายก็เริ่มมองเห็นตลาด แล้วก็เลยทำมาเฉพาะเลย โดยขายแยกเป็น template product เลยทีเดียว
  • Extract (ดึงมา) - Transformation (มีการเปลี่ยนแปลงข้อมูล) - Load (โหลดข้อมูลเข้าไปอยู่ใน warehouse)
  • ตอนดึงข้อมูลเข้า Data warehouses ข้อมูลอาจจะมี format ที่แตกต่างกัน ETL Tools จะทำหน้าที่แปลงให้ข้อมูลออกมาในแนวเดียวกัน หรือปรับโครงสร้างของข้อมูลให้สามารถนำไปวิเคราะห์ได้ ก่อนเก็บลง Data Warehouses โดย ETL Tools จะทำ data transformation ให้เรา
• Data Mining Tools ก็คล้ายๆกับ OLAP Tools นี่แหละ แต่มันจะคล้ายในแง่ที่ว่าใช้สำหรับวิเคราะห์ข้อมูลเหมือนกัน แต่ว่าลักษณะการวิเคราะห์ระหว่าง OLAP กับ Mining มันต่างกันค่อนข้างมาก โดยในเชิง OLAP จะวิเคราะห์ในเชิงของการที่ตายตัวว่าคุณอยากจะรู้อะไร เช่นอยากรู้ยอดขายราย 3 เดือน รายสาขา หา min, max ซึ่งค่อนข้างชัดเจนว่าจะหาหรือจะคำนวนอะไร แต่ Data Mining มักจะเป็นการเอาข้อมูลมาขุดค้นหาความสัมพันธ์กันของข้อมูล ว่ามันมีอะไรสัมพันธ์ (Association rules) กันอยู่ในนั้น Algorithm จึงค่อนข้างยุ่งยากและซับซ้อนกว่า ผลลัพธ์ที่ได้ออกมาจึงค่อนข้างน่าสนใจกว่า แต่เดี๋ยวนี้ Data Mining กับ OLAP มันเข้ามาใกล้กันมาก จนแยกค่อนข้างยากว่าอะไรเป็นอะไร
  • Data Mining จะออกแนวๆดูดวง เช่น คนที่มีลักษณะแบบนี้ พฤติกรรมแบบนี้ สุดท้ายแล้วจะเป็นแบบนี้ ทำแบบนี้ หรือจะคิดอีกแบบคือ Data Mining จะคล้ายๆกับโหราศาสตร์

เหล่านี้คือภาพรวมๆของ Business Intelligence ว่ามันคืออะไร และตอนต่อไปผมจะลงในรายละเอียดให้รู้จักกับ Data Warehouse ให้มากขึ้นกว่านี้อีกหน่อย

Related Link from Roti