Object Relational Mapping Method in Designing Database Structure for Mosque Management Information System Nidaul Hasanati 1, Rifal Rinaldi 2, Winangsari Pradani 3 Abstract Mosque for Muslims actually not just for prayers and other rituals of worship, but it s the center of all activities of Muslims. Prosperity of the mosque is a noble thing in Islam, so the mosque has many activities to be undertaken, like praying, da wah, education, healing conseling, Qur an club, Islamic youth and student club, Islamic arts, and so on. Besides praying, many other activities sometimes can not informed easily to the community without coming directly to the mosque. This paper contribute how to build mosque activities management information system, escpecially the database structure, to support data recording, scheduling of activities, as well as providing a good display is essential to attract the attention of external users to access information and also engage in the mosque activities. This paper focus in designing database structure using object-oriented method and then ORM (object Relational Mapping), that will be able to simplify both system developers that use the OODB (Object Oriented Database) or RDBMS (Relational Database Management System) to build this system. Keywords Object Relational Mapping, Mosque, Database I. INTRODUCTION Mosque for Muslims actually not just for prayers and other rituals of worship, but it s the center of all activities of Muslims. At the time of the Messenger Muhammad, the Prophet's Mosque serves as a place of worship, education center, information center, place for settling disputes, economic center, and also social and political center [1]. So, the mosque for Muslims has huge potential to build all aspects of human life. Prosperity of the mosque is a noble thing in Islam, so the mosque has many activities to be undertaken, like praying, da wah, education, healing conseling, Qur an club, Islamic youth and student club, Islamic arts, and so on. Praying is a usual activities in the mosque, but many other activities can not informed easily to the community without coming directly to the mosque. Nidaul Hasanati 1 is Lecturer of Information Engineering, Science and Technology Faculty, University of Al Azhar Indonesia; Phone: 0812-1835079; (e-mail: nida@uai.ac.id). Rifal Rinaldi 2, was also from Information Engineering, Science and Technology Faculty, University of Al Azhar Indonesia; (e -mail: rifalsehat@yahoo.com). Winangsari Pradani 3 is is Lecturer of Information Engineering, Science and Technology Faculty, University of Al Azhar Indonesia; (e -mail: winangsari@uai.ac). From the observations and interviews, most of data in mosque are still in the papers, that make difficult to look for. Any difficulties are found when make a schedule, sharing the exact composition of the schedule preacher, and determining the appropriate title or theme of sermon/lecture that has been done or not. Manual content documentation of the sermon, sometimes are difficult to search as well as slow down the performance time. Besides, the presence of preachers sometimes can t be controlled by mosque committee because it s not recorded in a neat yet available. Eventhough the management of the mosque want to know the responsibility of the preacher concerned to meet the schedule of the mosque, and also need decision-making regarding the performance of the preachers. Mosque management information system in this paper helps to manage the activities carried by mosque, include: First, the system can be recording data; such as activities and type of activities, imams, preacher/speaker, title and content of the sermon/lecture. Second, scheduling activities of mosques, both routine activities, such as praying 5 times, 5 minutes speach, sermon on Friday, Eid, Eid al-adha, etc; and additional activities such as assemblies of science, religion consulting, area of youth activities, education, healing conseling, Qur an club, Islamic arts, and so on. Third, providing attractive and good display to internal and external users to access information and also engage in the mosque activities. In 2013, Ministry of Religious Affairs of the Republic of Indonesia inaugurated The Mosque Information Systems called Sistem Informasi Masjid (SIMAK) [2]. This information systems can facilitate the process of data inventory mosques and prayer rooms in Indonesia. Mosque Information System which can be a tool of work units to plan, manage and monitor the management of assistance and data management mosque/prayer rooms in Indonesia. Different from the above, this article regarding how to design management information systems to handle activities in the mosque, particularly to design database structure. Because of many activities will be held in mosque, it s suitable when used object oriented design method. Currrently, information and communication technology is growing rapidly, so it can be a reference for system developers to buiild this system both in web based system [3] or mobile based system; by using the OODB (Object Oriented Database) or structural pattern with RDBMS (Relational Database Management System). This paper contribute how to 142
map object oriented design method to structural pattern in relational database, in terms of mosque activities, with still maintaining the performance of the database. examine these attributes and explore association types by these attributes. II. BASIC THEORY Object Relatioal Mapping is how domain model are mapped to structures in the relational database [4]. Mainly, there are patterns and techniques for mapping of objectoriented structures, such as inheritance hierarchies, aggregations, relations. While coping with relations we will consider different kinds of relations by cardinality and orientation. Strategies for mapping of inheritance, there are 3 ways: a) Hierarchy to a single table, this is probably the simplest approach for mapping of inheritance structures. Whole inheritance hierarchy is mapped to a single table, which should be named after most general class in the hierarchy. The table is equal to union of attributes of all classes in a hierarchy. Figure 1. Hierarchy to a single table a) Each class to its own table, every class in inheritance hierarchy is mapped to its own table. Note that also abstract classes have their tables. Every table has attributes of its corresponding class. There are no attributes inherited from super classes here. Figure 4. 1:1 association mapping Figure 5. 1:n association mapping Figure 6. m:n association mapping We can divide object associations into groups by criteria such as multiplicity, orientation or order. We will examine all of these criteria from the view of object-relational mapping. We will not consider deeply how multiplicity, orientation or order could be implemented in object-oriented environments. Instead, we will look how we can map these to relational database. Figure 2. Each class to its own table b) Concrete class to its own table. By this pattern we map every concrete class from inheritance hierarchy to its own table. Attributes of this class as well as attributes of all parent classes are mapped to this table. Figure 3. Concrete class to its own table Objects can be connected together and can reference each other. These connections are called associations, shows in Figure 4-6. Special cases of association are composition and aggregation. Associations have some attributes. We will Figure 7. Foreign key Agregation For mapping agregation, we can join the two class, becoming 1 table, both 1:1 agregattion or 1:n agregation. We can join the table As we need no database join operations, this approach brings good performance. On the other hand, maintainability of such solution is very poor. Imagine, if there is a change in the database schema, will change the structure of the table. For example, the addition or subtraction of attributes, then we will increase or decrease the amount of columns in the table. When using the Foreign key solution of aggregation pattern, we create separate database table for aggregated object type. Of course we have database table for aggregating object type. We add foreign key attribute to this table. 143
III. DISCUSSION A. Usecase Diagram These are the highest level of business requirements model of the system, pictured by usecase diagram in Figure 1and 2. This usecase diagram shows the interaction between actors and system. Actors in this systems are head of mosque management who view reports and control activities of mosque and the daily operational management who enter data and manage data in the system. In general, the capabilities of system are : 1) Manage Activities 2) Manage Person in Charge 3) Scheduling Activities 4) Documenting lecture/sermon material 5) Manage Rooms 6) Create Report 7) Print Documents Figure 9. Use Case Diagram (2) Figure 8. Use Case Diagram(1) B. Class Diagram Figure 10 shows the class diagram of The Mosque Management Information System. The structure of the pattern of the strategies used in class diagram using inheritance mapping strategy pattern Each class to its own table. Because it has several advantages, among others: 1. Can observe a heavy load on the root class table. 2. The use of this pattern is convenient in this situations where there is a significant overlap between the types. 3. The relational model is very flexible so maintainable (treatment) and an almost ideal spaceconsumption. But he downside of this pattern is a poor performance, because we need many join table to get full information about the object, roughly equal to the depth of the class inheritance hierarchy. Why we didn t use the Hierarchy to a single table or Concrete class to its own table for mapping inhetitance? If we use Hierarchy to a single table, drawback of resulting database schema is its space consumption. There are lots of NULLs and we can observe that with bigger amount of classes we have bigger amount of wasted space. Mosque has many types of activities, if the becoming only one table, there will be lots of NULLs when it s not a type of activitiy. Eventhough this structure has good performance because we need only one select to get particular object with all its properties. We need no additional joins. It has has maintenance of resulting scheme 144
is very easy. We also didn t use Concrete class to its own table, because we can also observe that even a small change causes a change in the object model of the whole object of the child tables turned. The use of this pattern is suitable in a situation where we assume that the object model will not change very often, while it could be activities in the mosque is often change Figure 11. Generic Table Structure C. Generic Table Structure Then generic table structure can be displayed in Figure 11. This section will explain the relationship table database created in this system, indicating the primary key that is marked with PK symbol, and foreign key marked with FK symbol that connect with othertables. IV. CONCLUSION Object Relatioal Mapping is how domain model are mapped to structures in the relational database. Each type of mapping strategies above has positive and negative impact for the performance of database. We have to consider what the best solution for mapping. The mapping strategy that used for mapping inheritance in this system is Each class to its own table. Because mosque has many activities and many types of activites that also can change anytime, so we have to choose the flexible model to maintain the data without changing the database structure and wasted a lot of space consumption. ACKNOWLEDGMENT The author would like to thank Lembaga Penelitian dan Pengabdian Masyarakat Universitas Al Azhar Indonesia (LP2M UAI) and Information Engineering Department UAI for funding the paper to participate in this seminar and to be publish in the proceeding. Figure 10. Class Diagram Mosque Management Information System REFERENCES [1] Aziz Muslim, Manajemen Pengelolaan Masjid, Aplikasia:Jurnal Aplikasi Ilmu-ilmu Agama, Dakwah Faculty UIN Sunan Kalijaga, Vol 5 No.2, December 2004. [2] Buku Panduan Sistem Informasi Masjid (SIMAS), Ministry of Religious Affairs of the Republic of Indonesia, 2013. [3] Achmad Alfian Hidayat, Sistem Informasi Manajemen Masjid (SIMM), Politeknik Elektronika Negeri Surabaya. [4] Orság Jaroslav, Object-Relational Mapping, Department Of Computer Science, Faculty Of Mathematics, Physics And Informatics, Comenius University, Bratislava, Slovakia, 2006, P. 25 34. [5] Whitten L. Jeffery, System Analysis and Design Methods 6ed, Mc Graw Hill, 2004, ch. 7 &11. Nida ul Hasanati was born in Jakarta, on July 18 1979. She is a lecturer in Information Engineering Department, Faculty of Science and Technology, University of Al Azhar Indonesia. This Author has many experiences in developing Software and Information System. She also interested in Database, Decision Support System, Intelligent System, and Big Data Processing. 145