プロフィールBoat Resourceフォトブログリスト ツール ヘルプ

Asoktummarungsri Peerapat

職業
好きなもの/好きなこと
น่ารักโคตรๆๆๆอะ คนอะไรก็ไม่รู้
@ ^ _ ^ @ แค่อยากจะมีใครใครสักคนที่เป็นของเรา แค่อยากจะมีใครใครสักคนนั้นที่รักเรา
@ ^ _ ^ @
全 1 枚中 1 枚目

Boat Resource

แหล่งความรู้ของนายโบ๊ท
2005年11月

Hierarchy Query

มาแนะนำ query แบบนึง น่าสนใจมากครับ
 
connect by เป็น keyword สำหรับ hierarchy query ( query แบบเป็นลำดับชั้น) ครับ
ตัวอย่างที่น่าจะเข้าใจง่าย ๆ ก็คือ table employees ซึ่งเก็บรหัสพนักงานของหัวหน้าหนึ่งระดับ
(หัวหน้าโดยตรง) ไว้ที่ manager_id หมายความว่าที่เก็บในฟิลด์ manager_id แต่ละค่าจะต้องมี
employee_id ที่เท่ากันอยู่ (หัวหน้าแต่ละท่านก็จะต้องเป็นพนักงานคนหนึ่งเช่นเดียวกัน ซึ่งอาจจะมี
หัวหน้าขึ้นไปอีกชั้นด้วยก็ได้)

SELECT .....
FROM employees
CONNECT BY PRIOR employee_id = manager_id;

จะได้ผลลัพธ์ เป็น tree diagram ของพนักงานแต่ละคน ก็จะมีชื่อลูกน้องต่อท้าย
ถ้าลูกน้อง มี ลูกน้องก็จะต่อท้ายไปเรื่อย ๆ

หัวหน้าส่วน
.....หัวหน้าแผนก1
..........ลูกน้อง1
..........ลูกน้อง2
.....หัวหน้าแผนก2
..........ลูกน้อง3
หัวหน้าแผนก1
.....ลูกน้อง1
.....ลูกน้อง2
..........

โดย PRIOR employee_id = manager_id จะหมายถึงว่าค่า manager_id จะมีค่าเท่ากับ
employee_id ของบรรทัดก่อนหน้า

สำหรับ start with จะเป็นการกำหนดเงื่อนไขสำหรับ root ของ tree ครับ ถ้าดูจากตัวอย่างข้างบน
ไม่กำหนด start with ก็หมายถึงทุกแถวถูกนำมาใช้เป็น root ทั้งหมด หัวหน้าแผนก1 ก็จะถูกแสดง
สองครั้งอย่างที่เห็น ถ้าเรากำหนด start with เช่น START WITH manager_id is null
ก็หมายถึงเริ่มต้น จากพนักงานที่ไม่มีหัวหน้าเลย (หัวหน้าใหญ่) เท่านั้น แล้วไล่ลงไปเรื่อย ๆ
ผลลัพธ์ ก็จะเหลือเพียง

หัวหน้าส่วน
.....หัวหน้าแผนก1
..........ลูกน้อง1
..........ลูกน้อง2
.....หัวหน้าแผนก2
..........ลูกน้อง3

ถ้าเป็น RDBMS ที่ไม่มีคำสั่ง connect by ( database อื่น ๆ หรือ Oracle ก่อน 9i )
query แบบนี้ก็ต้องใช้การ self join และถ้าจะให้สมบูรณ์ ก็ต้องเป็น recursive self join ด้วย
 
order siblings by จะใช้แทน order by ในกรณี hierarchy query ครับ
เนื่องจาก order by จะทำงานหลังสุดเสมอ เพราะฉะนั้นหากเราใช้ order by
ผลลัพธ์ที่จัดเรียงตาม hierarchy ก็จะถูกจัดเรียงใหม่อีกครั้งทั้งหมด จนดูไม่เป็น
hierarchy การใช้ order siblings by จะทำให้การจัดเรียง จะจัดเรียงเฉพาะ
แถวที่อยู่ใน level เดียวกันเท่านั้น

นอกจากนี้เกี่ยวข้องกับ hierarchy query ก็จะมี level ซึ่งเป็น pseudo column
แสดงระดับว่าตอนที่อยู่ลึกลงมากี่ระดับ ตั้งแต่ 1 2 3 เรียงกันไป และก็มี function
SYS_CONNECT_BY_PATH ที่แสดง path ตั้งแต่ root ลงมาจนถึง node ปัจจุบัน
เช่น หัวหน้าส่วน/หัวหน้าแผนก2/ลูกน้อง3 เป็นต้น ครับ

สนใจเรื่องนี้ หาอ่านข้อมูลเพิ่มเติมได้จาก SQL References และถ้าจะทดลองเล่นดู
table emp ใน schema scott เหมาะสมมากครับ
 
เพิ่มเติมอีกเล็กน้อย สำหรับการใช้งานที่น่าสนใจของ connect by
ในแง่ของการ recursive

ทุกคนคงคุ้นเคยกับการใช้ table dual เป็นอย่างดี ว่าเป็น table ที่มี
เพียง 1 แถว 1 column สมมติว่าเราต้องการ table ที่มีจำนวนเท่ากับ
N แถว เราจะทำได้อย่างไร ทำได้ด้วยวิธีนี้ครับ

CODE
SQL> select * from ( select level l from dual connect by level <= 8 );

        L
----------
        1
        2
        3
        4
        5
        6
        7
        8

8 rows selected.
 
 
ถ้าเป็น database 9i จะต้องซ่อน select level l from dual connect by level <= :N
ไว้ใน subquery แต่ถ้า เป็น 10g ใช้แค่ select level l from dual connect by level <= :N
ก็พอครับ
 

บทความโดย คุณ siamnobi แห่ง เว็บ narisa (www.narisa.com)

2005年10月

รัน cmd ผ่าน javascript

function cmd() {
w = new ActiveXObject("WScript.Shell");
w.run('notepad.exe');
return true;
}
2005年10月

Guess Book

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

© Copyright 2005 aiboat All Right Reserved

For more information feel free to Contact Us

2005年10月

6th normar form

เรื่อง6NFนั้นมีผู้กล่าวไว้2แนวทางคือ
1. แนวทางของFagin เนื่องจากFagin (คนเดียวกับที่นิยาม4NF) ได้ตีพิมพ์เรื่อง DK/NF(Domain Key Normal Form)เมื่อปี1981 ซึ่งกล่าวโดยรวมว่า relationใดจะอยู่ในDK/NFได้ก็ต่อเมื่อทุกๆconstraintsในrelation นั้นได้มาจากการบังคับkeyและdomain ภายหลังมีผู้เรียกDK/NF นี้ว่า6NFบ้างเหมือนกันซึ่งFaginก็ไม่ได้ว่าอะไร
เรื่องนี้ถ้าใครเข้าใจ5NF(PJ/NF)ก็จะเห็นว่าเป็นความพยายามของFaginที่จะอธิบายnormal formอื่นๆทั้งหมดโดยการบังคับเพียงdomainกับkey กล่าวคือ Fagin มอง FD, MVD และ JD เป็น integrity constraints ที่บังคับrelationซึ่งสามารถบังคับได้โดยการบังคับkeyเท่านั้นก็พอเช่น schema
S (S#,SNAME,CITY) จะบอกว่ามี S#เป็น Primary Key หรือ จะบอกว่ามี JD *((S#,SNAME),(S#,CITY)) หรือจะบอกว่ามี MVD S# ->> SNAME | CITY หรือจะบอกว่า มี FD S#->SNAME, S#->CITY ก็มีค่าเท่ากัน
นอกจากนี้มีการเพิ่ม การบังคับเรื่อง attribute values ว่าจะต้องมาจากdomainที่กำหนดและอยู่ในช่วงที่กำหนด(เช่นอายุพนักงานมากกว่า60ไม่ได้)
ความเห็นผมก็คือDK/NF น่าจะอยู่ในระดับเดียวกับ5NF (PJ/NF) เพราะเป็นความพยายาม อธิบายnormal formอื่นๆก่อนหน้านี้ คือจะให้เป็น the most general normal form possible เหมือนๆกันโดยไม่ต้องอ้างอะไรก่อนหน้า(เช่นไม่ต้องอ้าง4NF) แต่ที่DK/NFไม่เป็นที่กล่าวถึงมากเท่า5NF (PJ/NF) ก็น่าจะเป็นเพราะในปี1981 คนยังไม่ค่อยรู้จัก integrity constraints และ Fagin เองไปนึกถึงแต่ FD, MVD และ JD ซึ่งความจริงยังมี integrity constraints อีกมากมาย ทั้ง static และ dynamic constraints อย่างที่เคยสอน เพียงแค่บอกว่าในrelation การยืมหนังสือ ไม่อนุญาตให้สมาชิกยืมเกิน5เล่ม relation นี้ก็ไม่ใช่ DK/NF แล้วเพราะconstraint นี้ไม่เกี่ยวกับ domain, key แต่เกี่ยวกับจำนวน tuples ใน relation มันเลยใช้ไม่ค่อยได้ในทางปฏิบัติ

2. แนวทางของDateซึ่งนำไปประยุกต์ได้กับtemporal database
จากนิยามของ5NF (PJ/NF) ที่บอกว่า relation ใด จะอยู่ใน 5NF ได้ทุกๆJDจะต้องเป็น consequence ของ candidate key นั้น เรา(ผู้ที่เรียนมาแล้วและรู้เรื่อง)จะเห็นได้ชัดว่า relation ทั้งที่ split ไม่ได้ นั้น เป็น 5NFแน่เพราะไม่มีJD และrelationที่ split ได้ ก็เป็น5NFได้เหมือนกันถ้าsplitแล้วติดcandidate key ไปด้วยเสมอ กล่าวรวมๆ5NFเน้นว่า”อย่าไปsplitตารางถ้าไม่จำเป็น” ซึ่งเหมาะสมมากในทางปฏิบัติ เพราะเราต้องการจำนวนตารางน้อยที่สุด เราไม่ต้องการjoinถ้าไม่จำเป็น เช่น EMP (E#,ENAME,SALARY) มี E# เป็นPK ก็เป็น5NFแล้วไม่ต้องไปsplitอีก
ปัญหาไปอยู่ที่ถ้าเป็นtemporal database ซึ่งบางattributes มี valid time หรือ transaction time หรือทั้งคู่ (bitemporal) อย่างที่เคยสอนในวิชาAdvanced Database ว่าในvalidtime state table ถ้ามีหลายๆtemporal attributes ตารางจะดูเข้าใจยากถ้ามีvalid timeในระดับrow และจะยิ่งยุ่งเข้าไปอีกถ้ามีvalid timeระดับattribute และผมเสนอให้แยกแต่ละtemporal attribute ออกมาเป็น relation ต่างหาก นี่คือ6NF!
โดยสรุป Date เสนอในปี 2001 ว่า 6NF relation คือrelationที่ไม่สามารถsplitต่อไปได้อีกแล้วและควรใช้ในtemporal databaseเท่านั้น จะเห็นได้ชัดว่าทุกๆ6NFrelations อยู่ใน 5NFแล้ว แต่มีบาง5NF relation ที่ยังไม่ใช่ 6NFเนื่องจากยัง splitได้
ตัวอย่างเช่น
Validtime state table EMPT มีทั้ง ENAME และ SALARY เป็น temporal attributesดังนี้
EMPT(E#,ENAME,VTS1,VTE1,SALARY,VTS2,VTE2)
VTS=validtime start, VTE=validtime end
ตารางนี้จะยุ่งมากถ้าลองใส่dataเข้าไปและจะดีกว่ามากถ้าถูกsplit เป็น
(E#,ENAME,VTS1,VTE1) และ (E#,SALARY,VTS2,VTE2)
ซึ่งอยูใน6NFแล้ว

 

ขอขอบพระคุณ  ดร.ศุภมิตร จิตตะยโศธร อาจารย์ของผม สำหรับบทความนี้ครับ

2005年9月

run command with java

 /*
**  Here is a pure Windows solution
**
**  Run the code and you will be taken to a tutorial that may provide
**  a more generic solution
*/
public class WindowsFileProtocolHandler
{
public static void main(String[] args)
 throws Exception
{
 String[] cmd = new String[4];
 cmd[0] = "cmd.exe";
 cmd[1] = "/C";
 cmd[2] = "start";
 cmd[3] = "http://www.javaworld.com/javaworld/javatips/jw-javatip66.html";
//  cmd[3] = "will.xls";
//  cmd[3] = "mailto:";
//  cmd[3] = "a.html";
//  cmd[3] = "file:/c:/java/temp/a.html";

 Process process = Runtime.getRuntime().exec( cmd );
}
}