TRANSFORMASI SEMANTIC OBJECT MODEL KE DALAM STRUKTUR DATABASE. Oviliani Yenty Yuliana ABSTRAK

Prosiding Seminar Nasional Sains dan Teknologi-II 2008 Universitas Lampung, 17-18 November 2008

TRANSFORMASI SEMANTIC OBJECT MODEL KE DALAM STRUKTUR DATABASE Oviliani Yenty Yuliana Jurusan Teknik Informatika FTI Universitas Kristen Petra Jl. Siwalankerto No. 121-131 Surabaya 60236 email: [email protected]

ABSTRAK Penelitian yang dilakukan bertujuan untuk mentransformasikan meta data Semantic Object Model (SOM) ke dalam perintah Structured Query Language (SQL). Penelitian ini merupakan penelitian lanjutan yang dilakukan oleh Yuliana dan Silvia (2008). Aplikasi dapat mentransformasikan meta data yang berisi object, attribute, dan constraint SOM ke dalam perintah SQL. Berdasarkan pengujian, SQL yang dihasilkan dapat membuat struktur data pada database Oracle. Dengan penyesuaian beberapa tipe data, SQL tersebut dapat membuat struktur data pada database SQL Server dan MySQL. Kata kunci: Forward Engineering, Semantic Object Model, Structured Query Language, Struktur Database

1. PENDAHULUAN SOM adalah suatu model data dengan paradigma obyek. SOM menyediakan sejumlah mekanisme yang mewakili keterkaitan antara data yang kompleks dan terstruktur untuk pembuatan aplikasi (Hammer, 1981). Untuk itu SOM dirancang untuk mengakomodasi rancangan aplikasi yang lebih baik dan menyediakan struktur database yang lebih kaya (Codd, 1979 dan Hull, 1987). Penelitian ini menggunakan simbol dan mekanisme SOM yang diusulkan oleh Kroenke (2006). Perancangan model data dengan pendekatan SOM untuk menunjang subsistem produksi dilakukan oleh Yuliana (2002). Terdapat dua aplikasi SOM, yakni: Salsa dan Tabledesigner. Namun aplikasi tersebut hanya menyediakan fasilitas untuk mentranformasikan SOM ke dalam Database Microsoft Access. Selain itu, aplikasi tersebut sulit diperoleh karena semua home page sudah tidak aktif. Kebutuhan aplikasi SOM akan semakin meningkat seiring meningkatnya kebutuhan rancang sistem yang berorientasi obyek. Untuk itu, Yuliana dan Suphamit (2007) meneliti transformasi SOM ke dalam XML Schema. Yuliana dan Silvia (2008) membuat aplikasi untuk mendesain database dengan pendekatan SOM. Namun aplikasi tersebut hanya menyediakan fasilitas transformasi SOM ke dalam Database Oracle. Mengingat terdapat produk database yang lain, maka aplikasi tersebut perlu dikembangkan. Penelitian yang dilakukan untuk adalah mentransformasikan SOM (object, ISBN : 978-979-1165-74-7

II-132


attribute, dan constraint) ke dalam perintah SQL. Peneliti Astrahan (1975) dan Chamberlin (1974) menyatakan SQL sebagai standart untuk berbagai produk database. Dengan demikian SOM dapat ditansformasikan ke dalam berbagai struktur database melalui perintah SQL. Sepengetahuan peneliti belum ada yang melakukan penelitian tersebut.

2. METODE PENELITIAN Metode yang dilakukan dalam penelitian ini adalah sebagai berikut: • Mendefinsikan kebutuhan, dalam pendahuluan diungkap perlu adanya aplikasi pentransformasi meta data SOM (hasil penelitian Yuliana dan Silvia) ke dalam SQL. • Analisa tipe data, dilakukan analisa berbagai tipe data pada database Oracle, SQL Server, dan MySQL. • Perancangan dan pembuatan aplikasi, pada tahap ini dilakukan perancangan algoritma dan pembuatan program pentransformasi meta data SOM ke dalam perintah pendefinisi struktur data database dalam SQL. • Pengujian sistem, dilakukan pengujian terhadap SQL yang dihasilkan aplikasi kemudian ditarik kesimpulan.

3. HASIL DAN PEMBAHASAN Penelitian ini memanfaatkan studi kasus yang digunakan oleh Yuliana (2007) yang tampak pada Gambar 1. Studi kasus tersebut mewakili ketujuh tipe object yang diusulkan oleh Kroenke (2006), yakni: simple, composite, archetype/version, parent/subtype, compound, association, dan hybrid. Pemahaman simbol (object, attribute, identifier, dan cardinality) dan mekanisme SOM dapat dilihat pada Kroenke (2006). Sedangkan pemahaman simbol dan mekanisme SOM dalam studi kasus administrasi proyek dapat dilihat pada Yuliana (2008).

ISBN : 978-979-1165-74-7

II-133


PROJECT ID ProjectID ProjectStart ProjectEnd

APARTMENT ID ApartmenID BUILDING

1.1

ApartmentNo

1.1

NumberBedRooms SquareFeet

1.1

1.1 1.1

MATERIAL-REQUISITION ID RequisitionId 1.1 DateRequest 1.1 1.1

PROJECT LineItem ID MATERIAL

1.1

Quantity Price Total 1.1

1.1 1.1 1.N

1.1 0.1 0.1

BUILDING

1.1

ASSIGNMENT

1.N

MATERIALREQUISITION

0.N

BUILDING ID Name Address Street 1.1 City 1.1 State 0.1 Zip 0.1

1.1

1.1

APARTMENT

1.N

PROJECT

1.N

ASSIGNMENT ID AssignmentID 1.1

PROJECT ARCHITECT

1.1

AssignmentDate MaxBudgetedHours MaxLaborCost MaxMaterialCost

1.1 0.1 0.1 0.1

EMPLOYEE ID EmployeeNumber ID EmployeeName Telephone HireDate Salary

1.1 1.1 0.N 0.1 0.1

SUPERVISOR

0.ST

ARCHITECT

0.ST

1.1

ARCHITECT

MATERIAL ID MaterialId MaterialDescription UnitPrice

1.1 1.1 1.1

MATERIALREQUISITION

1.N

SUPERVISOR EMPLOYEE

P

SuperTitle SuperLevel

1.1 1.1

EMPLOYEE

P

ArcBonusEarned ArcBonusPaid

0.1 0.1

ASSIGNMENT

1.N

Gambar 1. Model data SOM studi kasus administrasi proyek Sumber: Yuliana (2007) Untuk menunjang penggambaran model data SOM, Yuliana (2008) mengusulkan meta skema seperti yang tampak pada Gambar 2. Kesembilan obyek pada Gambar 1 disimpan dalam Tabel OBJECT. Sedangkan Simple Attribute yang berada dalam obyek maupun dalam group disimpan dalam Tabel SIMPLE. Group Attribute disimpan dalam Tabel GROUP. Object Attribute disimpan dalam Tabel LOKASI_OBJECT. Masing-masing atribut tersebut harus menyertakan lokasi atribut tersebut. Dengan demikian, transformasi SOM ke dalam struktur database dilakukan dengan mentransformasikan meta skema SOM ke dalam perintah SQL. Transformasi meliputi 3 proses transformasi, yakni: object, attribute, dan constraint (primary key, null/ not null, dan foreign key). LOKASI_OBJECT

SIMPLE

KodeObject (FK) LokasiObject (FK,FK)

CHAR(3) CHAR(3)

Max (O) ID (O)

CHAR(2) CHAR(3)

OBJECT

KodeSimple

CHAR(4)

KodeObject

CHAR(3)

NamaSimple TipeData PanjangData (O) Min Max (O) ID (O) Lokasi (FK,FK)

CHAR(30) CHAR(10) INTEGER BIT CHAR(1) CHAR(3) CHAR(4)

NamaObject PosisiX (O) PosisiY (O)

CHAR(30) INTEGER INTEGER

GROUP KodeGroup

CHAR(3)

NamaGroup Max ID (O) LokasiGroup (FK)

CHAR(30) CHAR(1) CHAR(3) CHAR(3)

Gambar 2. Meta skema aplikasi SOM,Yuliana (2008)

ISBN : 978-979-1165-74-7

II-134


Proses transformasi object dan simple attribute ditunjukkan dalam potongan program (modul) pada Gambar L1. Tabel OBJECT dan SIMPLE (max=1) menjadi sumber data untuk proses tersebut. NamaObject dari Tabel OBJECT menjadi nama tabel, NamaSimple dan TipeData dari Tabel SIMPLE menjadi nama dan tipe atribut untuk tabel yang dibuat. Selain itu, Min=0 digunakan untuk mendefinisikan constraint null dan Min=1 untuk constraint not null. Sebagai contoh, perintah SQL yang dihasilkan oleh modul pada Gambar L1 untuk model data pada Gambar 1 adalah baris ke-1 sampai dengan baris ke-46 pada Gambar 3. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.

CREATE TABLE EMPLOYEE( EmployeeNumber Char(3) NOT NULL, EmployeeName Char(30) NOT NULL, HireDate Date NULL, Salary Number NULL); CREATE TABLE APARTMENT( NumberOfBedRooms Integer NOT NULL, SquareFeet Number NOT NULL, ApartmentNumber Char(4) NOT NULL, Name Char(30) NOT NULL); CREATE TABLE SUPERVISOR( SuperTitle Char(10) NOT NULL, SuperLevel Char(10) NOT NULL, EmployeeNumber Char(3) NOT NULL); CREATE TABLE PROJECT( ProjectID Char(3) NOT NULL, ProjectStart Date NULL, ProjectEnd Date NULL, Name Char(30) NOT NULL); CREATE TABLE ARCHITECT( ArcBonusEarned Number NULL, ArcBonusPaid Number NULL, EmployeeNumber Char(3) NOT NULL); CREATE TABLE ASSIGNMENT( Assignmentdate Date NOT NULL, MaxBudgetedHours Integer NULL, MaxLaborCost Number NULL,

28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54.

MaxMaterialCost Number NULL, ProjectID Char(3) NOT NULL, EmployeeNumber Char(3) NOT NULL); CREATE TABLE MATERIAL( MaterialID Char(3) NOT NULL, MaterialDescription Char(35) NOT NULL, UnitPrice Number NOT NULL); CREATE TABLE BUILDING( Name Char(30) NOT NULL, Street Char(25) NOT NULL, City Char(20) NOT NULL, State Char(5) NULL, Zip Char(5) NULL); CREATE TABLE MATERIAL_REQUISITION( RequisitionID Number NOT NULL, DateRequest Date NOT NULL, SubTotal Number NOT NULL, Tax Number NOT NULL, ProjectID Char(3) NOT NULL); CREATE TABLE LINEITEM( Quantity Number NOT NULL, Price Number NOT NULL, RequisitionID Number NOT NULL, MaterialID Char(3) NOT NULL); CREATE TABLE TELEPHONE( Telephone Char(15) NULL, EmployeeNumber Char(3) NOT NULL);

Gambar 3. SQL untuk mendefinisikan object dan attribute SOM dalam database Proses transformasi value multi group attribute, misal group LineItem dalam obyek MATERIAL_REQUISITION pada Gambar 1, ditunjukkan dalam modul pada Gambar L2. Tabel SIMPLE, GROUP, dan LOKASI_OBJECT menjadi sumber data untuk proses tersebut. Perintah SQL yang dihasilkan tampak pada baris ke-47 sampai dengan baris ke-51 pada Gambar 3. Sedangkan proses transformasi value multi simple attribute, misal Telephone pada obyek EMPLOYEE pada Gambar 1, ditunjukkan dalam modul pada Gambar L3. Tabel SIMPLE menjadi sumber data untuk proses tersebut. Perintah SQL yang dihasilkan tampak pada baris ke-52 sampai dengan baris ke-54 pada Gambar 3. Proses pendefinisian primary key yang berasal dari simple attribute, misal ProjectID dalam obyek PROJECT, tampak dalam modul pada Gambar L4. Table SIMPLE (dengan kriteria ID=’IDU’) dan OBJECT menjadi sumber data untuk proses tersebut. Perintah SQL yang dihasilkan untuk model data pada Gambar 1 tampak pada baris ke-1 sampai ISBN : 978-979-1165-74-7

II-135


dengan baris ke-5 pada Gambar 4. Untuk mendefinisikan primary key single value group attribute, misal ApartmentID pada obyek APARTMENT, tampak dalam modul pada Gambar L5. Table GROUP (dengan kriteria ID=’IDU’) OBJECT, dan LOKASI_OBJECT menjadi sumber data untuk proses tersebut. Perintah SQL yang dihasilkan untuk model data pada Gambar 1 tampak pada baris ke-6 dan baris ke-7 pada Gambar 4. Sedangkan pendefinisian primary key multi value group attribute, misal group LineItem pada obyek APARTMENT, tampak dalam modul pada Gambar L6. Perintah SQL yang dihasilkan untuk model data pada Gambar 1 tampak pada baris ke-8 dan baris ke-9 pada Gambar 4. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.

ALTER TABLE EMPLOYEE ADD CONSTRAINT EMPLOYEEPK PRIMARY KEY(EmployeeNumber); ALTER TABLE PROJECT ADD CONSTRAINT PROJECTPK PRIMARY KEY(ProjectID); ALTER TABLE MATERIAL ADD CONSTRAINT MATERIALPK PRIMARY KEY(MaterialID); ALTER TABLE MATERIAL_REQUISITION ADD CONSTRAINT MATERIAL_REQUISITIONPK PRIMARY KEY(RequisitionID); ALTER TABLE BUILDING ADD CONSTRAINT BUILDINGPK PRIMARY KEY(Name); ALTER TABLE APARTMENT ADD CONSTRAINT APARTMENTPK PRIMARY KEY(Name,ApartmentNumber); ALTER TABLE ASSIGNMENT ADD CONSTRAINT ASSIGNMENTPK PRIMARY KEY(ProjectID,EmployeeNumber); ALTER TABLE LINEITEM ADD CONSTRAINT LINEITEMPK PRIMARY KEY(RequisitionID,MaterialID); ALTER TABLE TELEPHONE ADD CONSTRAINT TELEPHONEPK PRIMARY KEY(EmployeeNumber,Telephone); ALTER TABLE SUPERVISOR ADD CONSTRAINT SUPERVISORPK PRIMARY KEY(EmployeeNumber); ALTER TABLE ARCHITECT ADD CONSTRAINT ARCHITECTPK PRIMARY KEY(EmployeeNumber); ALTER TABLE SUPERVISOR ADD CONSTRAINT SUPERVISORFK FOREIGN KEY(EmployeeNumber) REFERENCES EMPLOYEE(EmployeeNumber); ALTER TABLE ARCHITECT ADD CONSTRAINT ARCHITECTFK FOREIGN KEY(EmployeeNumber) REFERENCES EMPLOYEE(EmployeeNumber); ALTER TABLE LINEITEM ADD CONSTRAINT LINEITEMFK2 FOREIGN KEY(RequisitionID) REFERENCES MATERIAL_REQUISITION(RequisitionID); ALTER TABLE TELEPHONE ADD CONSTRAINT TELEPHONEFK FOREIGN KEY(EmployeeNumber) REFERENCES EMPLOYEE(EmployeeNumber); ALTER TABLE APARTMENT ADD CONSTRAINT APARTMENTFK FOREIGN KEY(Name) REFERENCES BUILDING(Name); ALTER TABLE PROJECT ADD CONSTRAINT PROJECTFK FOREIGN KEY(Name) REFERENCES BUILDING(Name); ALTER TABLE ASSIGNMENT ADD CONSTRAINT ASSIGNMENTFK1 FOREIGN KEY(ProjectID) REFERENCES PROJECT(ProjectID); ALTER TABLE ASSIGNMENT ADD CONSTRAINT ASSIGNMENTFK2 FOREIGN KEY(EmployeeNumber) REFERENCES ARCHITECT(EmployeeNumber); ALTER TABLE MATERIAL_REQUISITION ADD CONSTRAINT MATERIAL_REQUISITIONFK FOREIGN KEY(ProjectID) REFERENCES PROJECT(ProjectID); ALTER TABLE LINEITEM ADD CONSTRAINT LINEITEMFK1 FOREIGN KEY(MaterialID) REFERENCES MATERIAL(MaterialID);

Gambar 4. SQL untuk mendefinisikan constraint SOM dalam database Pendefinisian relasi antara parent/subtype object, contoh object attribute SUPERVISOR dan ASSIGNMENT pada obyek EMPLOYEE, tampak dalam modul pada Gambar L7. Tabel LOKASI_OBJECT menjadi sumber data untuk perintah tersebut. Perintah SQL yang dihasilkan untuk contoh tersebut tampak pada baris ke-12 dan baris ke-13 pada Gambar 4. Pendefinisian relasi multi value group attribut dengan obyek dimana group tersebut berada tampak dalam modul pada Gambar L8. Perintah SQL yang dihasilkan tampak pada baris ke-14 Gambar 4. Sedangkan

ISBN : 978-979-1165-74-7

II-136


pendefinisian relasi multi value single attribut dengan obyek dimana atribut tersebut berada tampak dalam modul pada Gambar L9. Perintah SQL yang dihasilkan tampak pada baris ke-15 Gambar 4. Pendefinisian relasi antara obyek selain yang dibahas di atas tampak dalam modul pada Gambar L10. Perintah SQL yang dihasilkan tampak pada baris ke-16 sampai dengan baris ke-21 Gambar 4.

4. KESIMPULAN DAN SARAN Berdasarkan pengujian terhadap perintah SQL yang dihasilkan (Gambar 3 dan Gambar 4) pada Database Oracle, menunjukan semua tabel dan constraint dapat terbentuk secara sukses. Namun perintah SQL tersebut tidak bisa dioperasikan pada Database SQL Server dan MySQL. Setelah dilakukan beberapa penyesuaian tipe data, misalnya Date dijadikan DateTime dan Number dijadikan Numeric, maka perintah SQL tersebut dapat dioperasikan pada Database SQL Server. Dengan adanya penambahan fasilitas transformasi meta data ke dalam perintah SQL dan agar perintah SQL tersebut dapat dioperasikan pada berbagai produk database, maka aplikasi pendesain model data SOM disarankan untuk dimodifikasi. Pemakai harus ditanya produk database yang digunakan. Dengan demikian dapat ditampilkan tipe data yang sesuai dengan produk database tersebut saat pemakai mendefinisikan property attribute.

DAFTAR PUSTAKA Astrahan, M. M. and Chamberlin, D. D. 1975. Implementation of a Structured English Query Language. Journal of Communication of the ACM, Vol 18, No. 10, 580-588. Chamberlin, D. D. and Boyce, R. F. 1974. SEQUEL: A Structured English Query Language. Proceeding of the ACM-SIGMOD workshop on Data Description, Access, and Control, 249264. Codd, E. F. 1979. Extending the Database Relational Model to Capture More Meaning. ACM Transactions on Database Systems Journal, Vol. 4, No. 4, 397-434. Hammer, M. and Dennis M. 1981. Database Description with SDM: A Semantic Database Model. ACM Transactions on Database Systems, Vol. 6, No. 3, 351-386. Hull, R. and Roger K. 1987. Semantic Database Modeling: Survey, Applications, and Research Issues. ACM Computing Surveys, Vol. 19, No. 3, 26-36. Kroenke, D. M. 2006. Database Processing: Fundamentals, Design, and Implementation. Prentice Hall, New Jersey, p. 609-641. Yuliana, O. Y. 2002. Rancangan Database Subsistem Produksi dengan Pendekatan Semantic Object Model. Jurnal Teknik Industri, Vol. 4, No. 1, 8-18. Yuliana, O. Y. and Suphamit C. 2007. Semantic Object Model and Flat XML Schema. Proceeding of the first International Conference on Soft Computing, Intelligent System and Information Technology, 160-167.

ISBN : 978-979-1165-74-7

II-137


Yuliana, O. Y. dan Silvia, R. 2008. Pembuatan Aplikasi untuk Mendesain Basis Data Berdasarkan Semantic Object Model. Prosiding Seminar Nasional KOMMIT 2008, Vol. 5, 579-586. http://coolstrategy.com/som.htm Tabledesigner : Tabledesigner-Semantic Object Modeling.

ISBN : 978-979-1165-74-7

II-138

TRANSFORMASI SEMANTIC OBJECT MODEL KE DALAM STRUKTUR DATABASE. Oviliani Yenty Yuliana ABSTRAK

Recommend Documents