Migrating From MS Access To MySQL

คุณพร้อมหรือยัง ที่จะย้าย MS Access ไปยัง MySQL ถ้าไม่ยังพร้อม บทความนี้ จะเสนอแนะแนวทางการ Migrate เพื่อใช้สำหรับองค์กรของคุณ ตามผลสำรวจเมื่อเร็วๆ นี้พบว่ามากกว่า 20% ของผู้ใช้ MySQL ได้มีการวางแผนที่จะ Migrate จากแอพพลิเคชัน Access ไปยัง MySQL ภายในช่วง 12 เดือนข้างหน้านี้ แต่อย่างไรก็ตาม ถ้าค้นหาเอกสารที่เกี่ยวกับการ Migrate แล้วกลับจะพบว่า ยังมีเอกสารจำนวนไม่มากนักที่อธิบายแนวทางสำหรับการจัดการ Migration ที่สมบูรณ์เพียงพอ

ดังนั้น บทความนี้ได้สรุปข้อมูลจากการประชุม “MS Access Migration” ที่ 2007 MySQL User Group ซึ่งจัดงานขึ้นที่รัฐแคลิฟอร์เนีย โดยในการประชุมได้รวบรวม MySQL users จำนวนมากที่มีเป้าหมาย เพื่อกำหนดปัจจัยที่สำคัญที่ทำให้การ Migrate จาก MS Access Application ไปยัง MySQL ให้ประสบความสำเร็จ

แต่เนื่องจากแอพพลิเคชันสำหรับ MS Access ถูกสร้างในลักษณะเฉพาะ ผู้ใช้ MySQL จึงได้สรุปถึง 2 ปัญหาของ Migration ที่เกิดบ่อยๆ ดังนี้
• ปัญหาในเรื่องของ Data migration issues โดยจะทำให้การแปลงข้อมูลของ MS Access จะทำได้ยาก เนื่องจากการออกแบบรูปแบบของข้อมูลที่ไม่มีคุณภาพ และข้อมูลที่เก็บก็มีคุณภาพต่ำเกินไป
• ปัญหาในเรื่องของ Application migration issues ซึ่งแอพพลิเคชัน MS Access มักมีความผิดพลาดของการออกแบบ หรือลอจิกในโปรแกรมและรายงาน ทำให้ไม่สามารถทำการแปลงแอพพลิเคชันได้โดยอัตโนมัติ

ในความคิดเห็นส่วนใหญ่ในการประชุม ได้กำหนดแนวทางในการ Migration ให้ประสบความสำเร็จ โดยเบื้องต้นกำหนดเป็น 3 งาน ดังนี้
1. Rebuild the schema โดยจะเป็นการสร้าง Schema ใหม่ใน MySQL ตาม SQL best practice ซึ่งเป็นการยากกว่าการสร้าง MS Access schema ใหม่ใน MySQL
2. Clean the data ดึงข้อมูลจากฐานข้อมูล Access, ทำการ clean ข้อมูล และอิมพอร์ตข้อมูลเข้า MySQL schema ใหม่ที่สร้างขึ้นมา
3. Rewrite the application ทำการสร้างแอพพลิเคชัน Access ขึ้นมาใหม่ โดยใช้เครื่องมือในการพัฒนาบนเว็บพัฒนาแอพพลิเคชันทั้งหมด เช่น PHP หรือ ActiveGrid

แรงผลักดันในการขยับจาก MS Access ไปสู่ฐานข้อมูลในระดับที่ใหญ่กว่า

Access เป็นทางเลือกที่ผู้พัฒนาที่มีความชำนาญพอสมควรเลือกใช้กัน แต่ในหลายๆ ครั้งจะพบว่าการพัฒนาแอพพลิเคชันด้วยโปรแกรม MS Access มาจากการนำข้อมูลของบริษัทที่เป็นข้อมูลจากโปรแกรม MS Excel แล้วมีการแปลงไปยังฐานข้อมูลสำหรับ MS Access หลังจากนั้นก็จึงทำการเพิ่มฟอร์ม รวมทั้งรายงานรูปแบบต่าง ๆ เฉพาะงานนั้นต่อไป ทำให้แอพพลิเคชันเหล่านั้นถูกพัฒนาขึ้นตามความต้องการเฉพาะงานไป

ในอีกมุมหนึ่ง สำหรับกลุ่มผู้ใช้ MySQL ได้กล่าวถึงแรงกดดันที่เพิ่มมากขึ้นสำหรับองค์กรที่ต้องการขยับแอพพลิเคชันที่พัฒนาขึ้นมาด้วย MS Access ไปสู่ฐานข้อมูลระดับใหญ่ขึ้นดังนี้
• ข้อมูลมีคุณภาพค่อนข้างต่ำ ในหลาย ๆ ครั้งพบว่าแอพพลิเคชันจาก Access นั้นมีข้อมูลที่เก็บล้าสมัยหรือ ข้อมูลที่เก็บเอาไว้มีปัญกหาอยู่ภายใน เนื่องจากการกำหนด รูปแบบหรือพฤติกรรมของข้อมูลไม่ดีพอ
• การรักษาความปลอดภัยต่ำ แอพพลิเคชัน Access ไม่มีการผสานกับระบบการรักษาความปลอดภัยขององค์กร และไม่มีระบบการรักษาความปลอดภัยในระดับสูง เช่น Role-based access controls
• ข้อจำกัดในการบริหารจัดการ ปัญหาใหญ่อีกข้อก็คือแอพพลิเคชันจาก Access ไม่สามารถจัดการจากศูนย์กลาง โดยหน่วยงานในฝ่ายไอทีได้
• ไม่สนับสนุนการทำงานแบบเว็บเบส โดยแนวโน้มในการพัฒนาเข้าสู่ยุคของเว็บแอพพลิเคชันนั้น ปัญหาข้อหนึ่งของแอพพลิเคชัน Access คือไม่สามารถเข้าถึงโดยผ่านเว็บได้
• ปัญหาในเรื่อง SOX compliance บ่อยครั้งที่ผู้ตรวจสอบของบริษัท จะระบุว่าซอร์สโค้ดที่สำคัญของแอพพลิเคชันที่พัฒนาขึ้นมาจาก Access นั้นมีความเสี่ยงที่จะไม่ปลอดภัยในการใช้งาน

ปัญหาที่เกิดจากข้อมูล

ในส่วนของ MySQL นั้นได้เตรียม MySQL Migration Tool เพื่อเตรียมการโอนย้ายข้อมูลเอาไว้ให้ โดยเครื่องมือดังกล่าวนี้จะทำการแปลงรูปแบบและพฤติกรรมทั้งหมดที่สำคัญและข้อมูลจากฐานข้อมูลให้เรียบร้อย แต่ Access จะต้องมี Schema และ ข้อมูลตาม Schema and data quality issues ซึ่งจะมีปัญหาอยู่ 2 เรื่องหลัก ๆ ในด้านของคุณภาพข้อมูลที่จะโอนย้ายที่พบกันลบ่อยได้แก่

1. รูปแบบของข้อมูลจาก Access นั้นไม่พร้อมสำหรับ SQL ซึ่งผู้พัฒนาโปรแกรมที่ใช้ Access ในการพัฒนาระบบโดยตลอด จะไม่ค่อยคุ้นเคยกับพื้นฐานการออกแบบ SQL Schema โดยสำหรับ MySQL DBA เห็นว่า Access schema ส่วนใหญ่จะมีลักษณะคล้ายกับสเปรดชีทจาก Excel มากกว่า classic SQL schema สำหรับตัวอย่างที่ทำให้เห็นเป็นเช่นนั้น เช่น schema ไม่มี primary key ไม่มี foreign key และไม่มี referential integrity constraints แบบนี้เป็นต้น
2. ข้อมูลใน Access ไม่พร้อมในการนำไปใช้ เนื่องจากในบางส่วนของเทเบิลไม่มีการกำหนดรูปแบบอย่างถูกต้อง ทำให้ข้อมูลในฐานข้อมูล Access สามารถเกิดปัญหาขึ้นมาได้ เช่น กรณีง่าย ๆ อย่างฟิลด์ประเภทข้อความ แต่มีการเก็บข้อความที่มีความหมายเป็นวันที่ แบบนี้เป็นต้น

ปัญหาที่เกิดจากแอพพลิเคชัน

ในข้างต้น เราได้แจงบางปัญหาในการย้ายข้อมูลจาก Access ไปยัง MySQL ให้พอเห็นภาพแล้ว ต่อไปเราต้องทำการย้ายทั้งฟอร์มและรายงานที่อยู่ร่วมกับแอพพลิเคชันของ Access เพื่อให้นำไปใช้งานได้เหมือนเดิม

ยิ่งไปกว่านั้น บ่อยครั้งได้มีการรวมหลาย ๆ แอพพลิเคชันที่พัฒนาขึ้นมาด้วย MS Access ให้กลายเป็นเว็บแอพพลิเคชันเพียงตัวเดียว และในทำนองเดียวกันก็ยังมีการรวมหลาย ๆ ฟอร์มที่สร้างขึ้นมาใน Access ให้เป็นฟอร์มเพียงชุดเดียวอีกด้วย ซึ่งผู้ใช้ MySQL ส่วนใหญ่จะเลือกการย้ายไปยังแอพพลิเคชันใหม่ โดยการเขียนแอพพลิเคชันใหม่ทั้งหมดเพื่อใช้ทดแทนแอพพลิเคชันเดิมที่เคยทำงานด้วย Access แต่ช่วงเริ่มต้น อาจกำหนดให้ Access ใช้ ODBC ในการ connect ไปยัง MySQL data ไปเบื้องต้นก่อน

เหตุผลที่เลือกการพัฒนาแอพพลิเคชันใหม่แทนแอพพลิเคชันที่ทำงานบน Access เนื่องจาก
• Quality issues ความไม่มั่นใจในลอจิกของแอพพลิเคชันต้นฉบับเดิมที่สร้างขึ้นด้วย MS Accessที่ไม่ได้พัฒนาโดยโปรแกรมเมอร์ภายในองค์กร หรือโปรแกรมเมอร์ที่เป็นผู้โอนย้าย
• วางแผนจะพัฒนาไปสู่เว็บแอพพลิเคชัน ซึ่งผู้ใช้ MySQL ส่วนใหญ่ชื่นชอบการ Migrate จากแอพพลิเคชันแบบ “legacy” จาก MS Access ไปยังสถาปัตยกรรมการทำงานผ่านเว็บที่แข็งแกร่งกว่า
• ความจำเป็นและข้อจำกัดทางด้านความปลอดภัย ผู้ใช้ MySQL มีความต้องการเพิ่มฟีเจอร์ในการรักษาความปลอดภัยในระดับเอ็นเตอร์ไพรส์ให้กับระบบ เช่น Siteminder/LDAP authentication และ Role-based access controls ซึ่งแน่นอนว่าระบบเดิมไม่สนับสนุนอยู่ก่อน

แต่แม้ว่าจะมีเครื่องมือที่ช่วยเปลี่ยนแอพพลิเคชันที่พัฒนาขึ้นมาด้วย MS Access ไปเป็นจาวาแอพพลิเคชันได้โดยอัตโนมัติก็ตาม แต่ยังมีเพียงจำนวนน้อยที่สามารถแปลงระบบได้โดยอัตโนมัติ ซึ่งในแนวทางที่ดีกว่าในการย้ายแอพพลิเคชัน MS Access ก็คือการใช้ภาษาสำหรับเขียนโค้ดขึ้นมาใหม่ ได้แก่ PHP หรือ Web 2.0 visual builder ได้แก่ ActiveGrid

พัฒนาแอพพลิเคชันอย่างรวดเร็วด้วย ActiveGrid

ผู้ใช้ MySQL มีแนทางในการโอนย้ายแอพพลิเคชันที่พัฒนาขึ้นจาก Access ไปยัง MySQL โดยการสร้างแอพพลแคชันใหม่ ซึ่งก็มีเครื่องมือสำหรับรองรับงานนี้อยู่หลายอย่างที่สามารถเร่งกระบวนการในการพัฒนาแอพพลิเคชันให้เร็วขึ้นได้ โดยสำหรับ ActiveGrid นั้นเป็น Web 2.0 visual builder สำหรับ MySQL ที่ช่วยงานในการโอนย้ายแอพพลิเคชันจาก Access ให้ง่ายขึ้นอย่างมาก ซึ่งนักพัฒนาแอพพลิเคชันที่ใช้ MS Access เป็นหลัก (และยังรวมไปถึง MySQL DBA) ต่างก็ชื่นชอบแนวทางแบบ Visual ในการสร้างแอพพลิเคชัน และไม่ค่อยมีความสนใจในการใช้จาวาเฟรมเวิร์กซึ่งซับซ้อนมากนัก ทำให้ ActiveGrid อยู่ในความคิดของนักพัฒนาเหล่านั้นในอันดับต้น ๆ

การสร้างแอพพลิเคชันจาก ActiveGrid นั้นเป็นเรื่องง่าย โดยมีการทำงานย่อยเพียงแค่ 3 ขั้นตอนพื้นฐานตาม Model-View-Controller (MVC) design pattern ดังนี้
1. Define the model เป็นขั้นตอนแรกในการออกแบบโมเดล โดย โมเดลใช้กำหนดข้อมูลที่ถูกใช้ในแอพพลิเคชันที่ประกอบไปด้วยเทเบิลในฐานข้อมูล และความสัมพันธ์ระหว่างเทเบิล ซึ่งผู้พัฒนาจะทำการระบุข้อมูลต่าง ๆ ลงไป โดยการอิมพอร์ตจากรูปแบบและพฤติกรรมต่าง ๆ ของฐานข้อมูลที่มีอยู่ หรือ ใช้ Visual data editor
2. Create the views ซึ่งในที่นี่มุมมอง หรือ View จะใช้อธิบายถึงเว็บเพจที่ถูกแสดงโดยแอพพลิเคชัน ซึ่ง ActiveGrid สามารถสร้าง Default Ajax web pages บนพื้นฐานของรูปแบบและพฤติกรรมของฐานข้อมูล หรือนักพัฒนาสามารถสร้างเว็บเพจ ขึ้นมาใหม่ โดยใช้ Visual screen builder ก็ได้
3. Build the controller(s) โดยที่ Controller จะจัดการการทำงานต่าง ๆ ภายในแอพพลิเคชัน ได้แก่ Navigation ระหว่างเว็บเพจกับข้อมูลที่ร้องขอ, ความปลอดภัยกับการให้บริการ โดยที่ผู้พัฒนาสามารถกำหนดการทำงานใหม่ ๆ ด้วย Visual action editor ที่สามารถเรียกเว็บเซอร์วิส หรือโมดูลที่สร้างขึ้นมาพิเศษที่เขียนด้วย Java หรือ Python ได้เช่นกัน

ลงมือโอนย้ายฐานข้อมูลจาก MS Access

ความคิดเห็นส่วนใหญ่ของผู้ใช้ MySQL กับเครื่องมือสำหรับแปลงฐานข้อมูลโดยอัตโนมัติสำหรับ MS Access นั้น มักไม่ประสบความสำเร็จ สำหรับตัวอย่างของเครื่องมือที่ใช้แปลงให้แอพพลิเคชันจาก Access ที่มีอยู่ให้เป็นจาวานั้น บ่อยครั้งจะพบว่าผลลัพธ์ที่เสร็จสมบูรณ์จะได้แค่ 80% ส่วนอีก 20% ที่เหลือจะต้องใช้เวลามากกว่า เพื่อค้นหาและแก้ไข

ดังนั้น แนวทางปฏิบัติที่ดีที่สุดสำหรับโอนย้ายข้อมูลจาก Access คือการสร้าง schema ใหม่, การตรวจสอบข้อมูล และต่อด้วยการเขียนแอพพลิเคชันขึ้นมาใหม่ แม้ว่าแนวทางนี้ต้องใช้เวลา แต่ก็เป็นแนวทางเดียวที่ทำให้มั่นใจได้ ว่าแอพพลิเคชันที่พัฒนาออกมาจะมีคุณภาพที่เพียงพอ เพื่อในการดูแลรักษาต่อไป

เราจะแสดงให้เห็นถึงกระบวนการแบบเป็นขั้นเป็นตอนในการโอนย้ายแอพพลิเคชันจาก MS Access ไปยัง MySQL ดังนี้
1. สร้าง schema ขึ้นมาใหม่
การสร้าง Schema ใหม่ใน MySQL ใหม่ตาม SQL best practices ซึ่งจะยากกว่าการสร้าง MS Access schema ใหม่ใน MySQL แต่ก็ทำให้แน่ใจถึงการกำหนดส่วนประกอบต่างๆ ได้อย่างเหมาะสมและครบถ้วน ได้แก่
1.1 Primary keys
1.2 Indexes ที่ใช้ในการค้นหาและการ Join column
1.3 Foreign keys สำหรับความสัมพันธ์ทั้งหมด
1.4 Default values สำหรับ columns
1.5 Null-allowed columns
1.6 Views

2. ตรวจสอบและแก้ไขข้อมูลเสียใหม่
การดึงข้อมูลออกมาจากฐานข้อมูล MS Access โดยการใช้เครื่องมือ MySQL Migration tools หรือ การเอ็กพอร์ตเป็น .CSV นั้น ก่อนการอิมพอร์ตข้อมูลจะต้องทำการตรวจสอบและแก้ไขข้อมูล ดังต่อไปนี้
2.1 ต้องทำให้แน่ใจถึง Primary key ที่เป็น Uniqueness
2.2 ต้องทำให้แน่ใจถึง Referential integrity คือ ตรวจสอบว่า Primary key ที่มีอยู่ครบสำหรับทุก Foreign key และต้องแน่ใจว่า Foreign key นั้น Uniqueness สำหรับความสัมพันธ์แบบ 1 to 1
2.3 ต้องทำให้แน่ใจถึง Non-null columns จะต้องมีค่ากำหนดอยู่
2.4 ต้องทำให้แน่ใจถึง Data types ต้องตรงกับข้อมูลที่เก็บ
2.5 ทำการ Import ข้อมูลที่ clean แล้วเข้า MySQL schema ใหม่

3.เขียนแอพพลิเคชันขึ้นมาใหม่
ตรวจสอบฟอร์ม, รายงาน และคิวรีของแอพพลิเคชันที่พัฒนาจาก Access หลังจากนั้น ก็ทำการออกแบบและสร้างฟอร์ม และรายงานสำหรับแอพพลิเคชันนั้น ๆ ขึ้นมาใหม่โดยใช้เครื่องมือการทำงานสำหรับเว็บ โดยจะมีขั้นตอนดังนี้
3.1 Import MySQL data schema เข้าไปยัง Visual builder tool เช่น ActiveGrid
3.2 สร้างเว็บเพจใหม่ที่เตรียมกราฟิกอินเทอร์เฟซสำหรับแอพพลิเคชัน โดยใช้ ActiveGrid page editor
3.3 กำหนดการทำงานที่เตรียมให้กับการทำงานที่ต้องการ สำหรับแอพพลิเคชัน โดยใช้ ActiveGrid action editor, Custom Java หรือ Python code ,หรือ Web services

สรุปสุดท้าย Practice ที่ดีที่สุดสำหรับการ Migration จาก Access ไปยัง MySQL คือการ Migrate ข้อมูลไปยัง Schema ใหม่ พร้อมกับการสร้างฟอร์มและรายงานสำหรับแอพพลิเคชันขึ้นมาใหม่ โดยใช้เครื่องมือการพัฒนาแบบเว็บเบส

MySQL สามารถเพิ่มระดับการรักษาความปลอดภัย และคุณภาพของข้อมูลให้กับแอพพลิเคชันได้ ทำให้โซลูชันฐานข้อมูลเป็นที่น่าดึงดูดใจสำหรับบริษัทมากขึ้น สำหรับในการ Migrate ในอนาคต