Towards Logical Level Design of Big Data

Transcription

1 Towards Logical Level Design of Big Data Shreya Banerjee 1, Renuka Shaw 1, Anirban Sarkar 1, Narayan C Debnath 2 1 Department of Computer Applications, National Institute of Technology, Durgapur, India 2 Department of Computer Science, Winona State University, MN, USA {shreya.banerjee85@gmail.com, shawrenuka@gmail.com, sarkar.anirban@gmail.com, ndebnath@winona.edu Abstract Now-a-days with the enormous synthesize and increasing use in the arena of cloud computing, smart devices, and business intelligence, Big Data also has become a growing area of research. Yet in literature existing approaches regarding logical level designing of Big Data is very rare. Most are about representation of both semi-structured and structured data and from the perspective of schema-base. But Big Data is combination of structured, semi-structured and unstructured data and its inherent character is schema-less. In this paper, a semi-structured conceptual model (Graph Object Oriented Semi Structured Data Model) has been undertaken to transform in JSON (Java Script Object Notation) schema in order to support logical level designing of Big Data. Further the logical level model is illustrated using a case study and implemented in a NoSQL document oriented database MongoDB. In the context, distinct logical characteristics of Big Data are recognized and inspected whether the required logical features are available in or not. Keywords Big Data; Logical Level Design; JSON schema transformation; Logical Level Characteristics; I. INTRODUCTION In recent days, Big Data is a very common term used in the province of internet and cloud computing. Big Data can be referred as the data of large data-set from petabyte to zeta byte (Volume), of different types from Facebook content to sensor data (Variety), generated in rapid rate (Velocity) and the data with various levels of uncertainty and reliability (Veracity). These four Vs are the main characteristics of Big Data [16]. With Volume the increasing size of the data set in the recent internet age is indicated. The second V Variety has been implied that the structured, semi- structured and unstructured - all types of data can be included within Big Data. The third V - Velocity is indicating that the Big Data is dynamic and schema-less. On the other hand Veracity implies that all the data are not accurate and relevant. All of these characteristics create some challenges regarding Big Data capture, data analysis, data storage and data visualization [8].To full-fill these challenges a conceptual and logical datamodel of Big Data is necessary to represent Big Data in concise and unambiguous manner. Schema-less data are realized as data which have no predefined schema or domain and schema-base data are those that have predefined schema. Big Data is inherently schemaless in nature as its type cannot be known in advance. NoSQL databases are emerging now-a-days to physically store large and heterogeneous Big Data efficiently [9]. These databases provide supports towards storage of both schema-less and schema-base data. NoSQL databases can be of four types column oriented data store, document database, graph database and key-value database [15]. Document databases store the data as a document in any format like XML [13] (Extensible Markup Language) or JSON [12] (Java Script Object Notation). Documents are grouped together in form of collection and different documents can have different types of fields [15]. MongoDB [11] is a kind of document database. Although physical implementation of Big Data is present, very few approaches are available in literature regarding both conceptual and logical data modeling and designing for Big Data and also of NoSQL databases. In [5], a data flow model is introduced that ranges over a class of higher order relations which are sufficiently expressive to represent a wide variety of structured, unstructured and semi-structured data. But this model only represents Big Data from the perspective of schema- base. Nothing is mentioned about representation of schema-less. In [6] a computational model p-dot is presented for Big Data analytics in a large distributed system. This model can works as a bridging model between different Big Data analytics software and different underlying software frameworks. But appropriate modeling constructs for Big Data is not referred. In [10], MongoDB is modeled using relational algebra. In this approach different relational algebra are modeled on MongoDB s collection. But the proposal is only about transformation of MongoDB s collection towards relational table and not about logical level design of Big Data. Efficient conceptual level design of Big Data is depending on the simultaneous representation of structured, semistructured and unstructured data [7] in schema-less form. A conceptual model of Big Data can be transformed towards a logical level data model represented in XML or JSON. JSON will be useful to represent logical model of Big Data than XML due to some benefits of JSON over XML. XML has some tags or known schema [13]. It does not strictly conform towards a formal constraint. It has some hierarchical structures which have nested some records that have no same schema [1]. Hence, XML is ideal to represent semi-structured data. On the other hand JSON is collection of name-value pairs that is suitable for representing semi-structured, unstructured and structured data [14]. XML objects are analyzed as DOMs (Document Object Mode), which takes a long time and are slower while JSON objects are analyzed as string arrays which can be much faster. So as compared to XML, JSON has obviously higher parsing efficiency and the advantage of easy preparation [14]. Beside, JSON is also suitable for cloud databases in order to serialize data. In this paper an attempt has been made to examine whether a semi-structured data model (Graph Object

2 Oriented Semi-Structured Data Model) proposed in [2] can be used as a conceptual model for representation of Big Data. Regarding this, has been transformed towards logical model to support Big Data and is inspected whether the necessary logical characteristics of Big Data are present in it or not. Moreover, this logical data model in JSON is further illustrated using a case study and implemented in MongoDB [11]. With these aforementioned objectives this paper is organized as follows. Brief description of is specified in Section II. Transformation rules from schema to JSON schema have been specified in section III. The transformation mechanism is illustrated using a case study and implemented in a NoSQL database MongoDB [11] in section IV. Finally, section V is about conclusion and future work. Fig. 1 is representation of the framework for the proposed work in this paper. JSON MONGODB CONCEPTUAL DATA MODEL LOGICAL DATA MODEL Fig. 1. Framework for the proposed work in this paper. PHYSICAL DATA MODEL II. BRIEF DESCRIPTION OF GRAPH OBJECT ORIENTED SEMI- STRUCTURED DATA MODEL The [2] extends the object oriented paradigm to model semi-structured data. Main construct types of this model are Elementary Semantic Group () that is a collection of related instances and Contextual Semantic Group () that is a collection of related. The proposed data model allows the entire semi-structured database to be viewed as a Graph (V, E) in layered organization. The vertices V are the different constructs of the model like or. Edges E of graph represent the relationships between or within the constructs of GOOSDM. Distinct modeling constructs and relationship types of GOOSDM with their graphical notations have been specified in Table I and Table II. III. PROPOSED TRANSFORMATION MECHANISM OF INTO JSON SCHEMA A systematic rule based transformation of to JSON schema is essential to express the semi-structured data at logical level more effectively [2]. There are some facilities of devising a transformation engine for conceptual model to logical model transformation. These facilities are separation of logical abstraction, proper representation of Big Data in order to store it physically in more suitable and unambiguous way, and providence of distinct choices to the database designers for designing different databases for same conceptual data model. For this purpose, in subsection A, set of rules have been proposed to generate the equivalent JSON schema from the semantic constructs and relationship types of a given schemata. In subsection B, correctness of model transformation from towards logical model is proved. Further, in section C, logical features of have been compared with the logical features of Big Data and inspect what are present in and what are not. TABLE I. SUMMARY OF CONSTRUCTS AND THEIR GRAPHICAL NOTATIONS Constructs Description Graphical Notation Determinant Annotation Connector TABLE II. Elementary Semantic Group Determinant vertex of any which will determine the other member vertices in the. Contextual Semantic Group Specialized form of. Provide information about the schema to the user Connect multiple associated s SUMMARY OF RELATIONSHIP TYPES AND THEIR GRAPHICAL NOTATIONS Description Relationships Defined between Containment Parent and constituent S and S Defined between s of same layer or adjacent layers. Defined between association and associated Link Defined between two adjacent layer parent and inherited Reference Defined either between and referred or between and referred Graphical Notation P: Particepation of instances in ; p: Particepation of instances in Containment; : Ordering option A. Transformation rules from towards JSON schema Rule based transformation of constructs and relationship types towards JSON schema are as follows Rule 1: A simple will be expressed as properties or items of either an object or an array respectively in JSON schema. Each properties and items can only be primitive type like strings, integer, number, Boolean and array. For example, City can be defined on attribute City to realize Student city. Any determinant s must be included in required array of JSON Schema. However its value will be programmatically

3 make unique due to JSON limitations. The equivalent representation in JSON schema is as given in Fig. 2. Rule 2: A Simple will be expressed as either an object Rule 9: Any upper layer with relationship with adjacent lower layer s will be expressed as an object or an array with nesting in JSON Schema. Upper layer Student City { type : object, properties : { City :{ type : string SID City Person Fig. 2. Representation of in JSON. or an array, in JSON schema. For example, Student can be defined to realize the detail of Student. The equivalent representation in JSON schema can be as given in Fig. 3. Student { Student : { type : object, properties :{ Fig. 3. Representation of in JSON. Rule 3: Annotation will be expressed by description keywords of JSON schema. Thus, annotation is represented as description which can be able to express detail information of schema as well as object of schema. Rule 4: A Reference of and will be expressed by $ref reference keyword which is member of JSON Object. For example, a reference of City can be defined on attribute City to realize a referential attribute on Student city. Rule 5: s of topmost layer will be treated as root object or root array declaration. Rule 6: Any lowest layer with containment of some s will be expressed as an object or an array nested within the root object or root array (). Participation constraint (p) can be expressed using maxitems and minitems within an array. However in case of object, participation can be implemented programmatically due to limitation in JSON. When ordering constraint ( ) value of an element is 1(order) then it can be expressed as an array and when it is 0(unorder) then it can be expressed as an object. Rule 7: Uppermost with containment of s, reference of s and adjacent lower layer s will be represented as root object or root array. Rule 8: Link relationship of with adjacent lower layer s or lower will be expressed as using extends keyword in JSON Schema. The equivalent representation of Link relationship in JSON schema is given in Fig. 4. Name DoB {"$schema":" tomer","description":"linkrelationship", "type":"object","properties": {Student":{"type":"object","properties": {"SID":{"type":"array", "minitems":1,"maxitems":1, "items":[{"type":"integer"], City :{ type : array, minitems :1, maxitems :6, "items":[{"type":"string"], "extends":"person","required":["sid"], "additionalproperties":false, "Person":{"type":"object","properties": {"Name":{"type":"string", "DoB":{"type":"string","required":["Name ], "additionalproperties":false Fig. 4. Representation of Link in JSON. will be treated as root object or root array. Rule 10: relationship between any two s in the same layer will be expressed as an object or an array with nesting in JSON Schema. Nesting mechanism is same as proposed in [2]. Participation (P) and ordering ( ) constraints of associated s will be same as specified in Rule 6.

4 Rule 11: N array relationship within a set of s spread over several layer will be expressed as an object or an array with nesting in JSON Schema. Nesting mechanism is same as proposed in [2]. Rule 12: With several relationships (composition of n-array and simple relationships) within a set of s spread over several layer will be expressed as an object or as an array with nesting in JSON schema. Nesting mechanism is same as proposed in [2]. The representation is in Fig. 5. B. Correctness of Transformation With the aid of the set of proposed transformation rules, described in Section A, conceptual level semi-structured data model like is transformed to the equivalent JSON Schema in logical level. The correctness of the model transformation can be proved using the structural correspondence approach described in Narayanan et al [4]. In every model transformation, there is a correlation or correspondence between parts of the input model and parts of the output model. In the approach of Narayanan et al. it is described that, if a transformation has resulted in the desired output models, there will be a verifiable structural correspondence between the source and target model instances that is decidable. Further, the transformation can be accepted as correct, if a node in the source model and its corresponding node in the target model satisfy some correspondence conditions. The Table III can be treated as the look-up table for the cross links between the source model () and target model (JSON Schema). The proposed set of rules will realize the correctness condition in model transformation. In the proposed approach, the correspondence rules must ensure that semantics and syntax for every constructs in the model and its instance being transformed into the JSON Schema model elements. Several examples have been illustrated for the proposed transformation rules to verify the correctness of correspondence mapping of schemata to the equivalent JSON Schema. C. Logical Representation of Big Data Logical representation of implies that the model supports hierarchical, non-hierarchical relations, n-array relationships, cardinality and participation of instances, heterogeneous structures. But the model is not in the position to model the constructs that can be appeared dynamically and whose structures are not predefined. On the other side logical model of Big Data support heterogeneous structures, hierarchical and non-hierarchical relationships, n-array relationships, cardinality, participation and most important it also supports schema-less data whose domain are not known in prior. Hence, to represent Big Data logically an important feature is essential which is about representing schema-less data and this characteristic is missing in. Table IV is about Student Course Teacher {"schema":" 04/schema#","title":" Example","type":"array","items": [{"Student" {"type": array","minitems":1,"maxitems" :2,"items": {"SID":{"type":"integer", "Name":{"type":"string", "Course":{"type":"array","minItems":1, "maxitems":2,"items": {"CID":{"type":"integer", "Cname":{"type":"string", "Teacher": {"type":"array","minitems":1, "maxitems":2, "items": {"NAME":{"type":"string","required":["NAME"], "additionalproperties":false, ],"additionalproperties":false, "required":["cid"] ],"additionalproperties":false, "required":["sid"] ] ] Fig. 5. Representation of in JSON. the description of what features are present in the to support logical modeling of Big Data and what is absent.

5 TABLE III. Constructs Determinant Annotation LOOK-UP TABLE FOR STRUCTURAL CORRESPONDANCE Graphical Notation Equivalent JSON Schema Representation Properities or items Must be included inside required field An object or an array Description Connector An object or an array with nesting from right to left order Containment as nested object or array within root object or array. An object or an array with nesting. Link Reference P values 1:1 or 0:1 or 1:N or 0:N An object or an array with nesting from right to left order Using extend key-word Using $ref declaration minitems or maxitems; But value of N should be some integer value provided by user 0:X or 1:X As anyof constraint value 1 or 0 An array or an object type IV. ILLUSTRATION OF TRANSFORMATION RULES USING A CASE STUDY In this section the proposed set of transformation rules are illustrated using a case study. In section A, a case study regarding Project Management System has been specified. In section B, data regarding the case study is physically stored in a NoSQL database MongoDB. TABLE IV. COMPARISON TABLE BETWEEN AND LOGICAL CHARECTERISTICS OF BIG DATA Features in Big Data logical model Hierarchical and non-hierarchical structure Ordering and non-ordering participation Irregular and Heterogeneous Structure Participation Constraint N-Array Relationship Document Centric and Mixed Content Schema less representation of data Representation of data with a particular time stamp Features in ABSENT ABSENT A. Description of the case study and representation in both and JSON schema The case study is about Project Management System (PMS) specified in [3] where a project has several members and members are associated with some departments. Individual members may or may not have publications. Moreover, each member may participate in any number of Projects. The database for PMS is purely semi-structured in nature as data are irregular and implicit in structure. The schema can be easily changed. The schema and JSON Schema for PMS have been shown in Fig 6 and Fig 7 respectively. B. Implementation of the case study in MongoDB The case study described in section A is physically stored in a NoSQL database MongDB [11] in this section. MongoDB is an open-source document database. MongoDB works on concept of collection and document. The Table V. shows the correspondence of the PMS case study constructs, constructs, JSON schema representation and Equivalent MongoDB constructs. A snapshot of the implementation of the case study in MongoDB has been displayed in Fig. 8. From the Table V it can be specified that all of the PMS case study constructs can be mapped towards MongoDB. As the case study is semi-structured and schema-base, it cannot be in a position to support Big Data characteristics. If the case Publication study become schema less by dynamically addition of any data for example Paper_Content, is unable to represent that data without knowing its structure or type in prior. But in MongoDB Paper_Content can be added dynamically without knowing its structure or type in advance. TABLE V. VARIOUS CONSTRUCT USED IN CASE STUDY PMS AND CORRESPONDING, JSON AND MONGODB CONSTRUCTS Case Study Constrcuts Correspondence Equivalent JSON Schema Representation Equivalent MongoDB ProjectCase An array Collection Project An array document Member An array document Department An array document Publication An array document Pname,MID, DID,PID between Project and Member 1:N, 1 1:N, 1 Project Fig. 6. schema for PMS. Properties Field value inside the document. and nested 1:1, 1 Member Department An array and its nested Item 1:1, 1 Project document andits nested member document

6 {"schema":" 04/schema#", "title":"pms CASE STUDY", "type":"array","items": [{"Project":{"type":"array", "minitems":1,"maxitems":2, "items":[{"type":"object", "properties": {"Pname":{"type":"string", "Member":{"type":"array", "maxitems":2,"items": [{"type":"object", "properties": {"MID":{"type":"integer", "Departmant":{"type":"array", "minitems":1,"maxitems":1, "items": [{"type":"object", "properties": {"DID":{"type":"integer, "additionalproperties":false, "required":["did] ],"additionalitems":false,"additionalproperties":false, "required":["mid"] ],"additionalitems":false, "Publication":{"type":"array", "minitems":1,"maxitems":2,"items": {"PID":{"type":"integer","additionalProperties":false, "required":["pid"] ],"additionalitems":false,"additionalproperties":false, "required":["pname"] ],"additionalitems":false ] Fig. 7. JSON schema for PMS. Fig. 8. Snapshot of the case study implemented in MongoDB. V. CONCLUSION AND FUTURE WORK In this paper a semi-structured schema based conceptual data model is transformed towards a logical model using JSON schema. Further the logical model is implemented in a NoSQL database MongoDB. After comparing logical characteristics of Big Data model with the logical characteristics of it can be stated that the provides supports partially towards the logical design of Big Data. Couple of drawbacks is present in towards modeling of Big Data. One is about not to represent schema-less data and another is unable to represent the data within a particular time-stamp. However, on the other side NoSQL database MongoDB can store both schema-base and schema-less data. So case-study data regarding can be stored in MongoDB. With the shortcoming of in the context of big data, the future work will focus on devising of a common conceptual model that support Big Data, NoSQL databases and hence both schema-base and schema-less databases. Further future work can be transformation of such conceptual model to logical model in order to support fully towards logical level design of Big Data.

7 REFERENCES [1] S. Abiteboul, P. Buneman, and D. Suciu, Data on the Web: From Relations to Semistructured Data and XML. Morgan Kaufman, [2] A. Sarkar, Conceptual Level Design of Semi-structured Database System: Graph-semantic Based Approach, International Journal of Advanced Computer Science and Applications (IJACSA),Vol.2, No.10, pp , November [3] A. Sarkar, R. Ganguly, R. K Chatterjee, Graph Semantic based Approach for Quering Semi-structured Database System, 22nd International Conference on Software Engineering and Data Engineering, Los Angeles, CA, pp , September [4] A. Narayanan, G. Karsai, Specifying the correctness properties of model transformations, Proc. of 3rd Int. workshop on Graph and model transformations (Int. Conf. on Software Engineering), pp , [5] S. Price, P. A. Flach, "A Higher-Order Data Flow Model for Heterogeneous Big Data", IEEE International Conference on Big Data, pp , [6] T. Luo, Y., Liao, G., Chen, & Y. Zhang, P-DOT: A model of computation for big data., In X. Hu, T. Y. Lin, V. Raghavan, B. W. Wah, R. A. Baeza-Yates, G. Fox, C. Shahabi, M. Smith, Q. Y. 0001, R. Ghani, W. Fan, R. Lempel & R. Nambiar (eds.), BigData Conference, pp , IEEE. ISBN: , [7] Oracle Corp., Oracle Information Architecture: An Architect s Guide to Big Data, [8] C.L.P. Chen, C.Y. Zhang, Data-intensive applications, challenges, techniques and technologies A survey on Big Data, Information Sciences, Volume 275, pp , ISSN , 10 August [9] J. Han, H. E., G. Le, J. Du, "Survey on NoSQL database," 6th International Conference on Pervasive Computing and Applications (ICPCA), 2011, pp , Oct [10] G. Zhao, W. Huang, S. Liang, Y. Tang, "Modeling MongoDB with Relational Model," Fourth International Conference on Emerging Intelligent Data and Web Technologies (EIDWT), 2013, pp , 9-11 Sept [11] MongoDB Manual, Accesed on 10th December, [12] JSON-Schema, Accessed on 5th December, [13] Extensible Markup Language (XML), Accessed on 4th December, [14] B. Lin, Y. Chen, X. Chen, Y. Yu, Comparison between JSON and XML in Applications on AJAX, International Conference on Computer Science and Service System (CSSS), pp , August, [15] K. Kaur, R. Rani,"Modeling and querying data in NoSQL databases," IEEE International Conference on Big Data,, pp.1-7, 6-9 Oct [16] M.D.Assuncao, R.N. Calheiros, S.Bianchi, M. A. S. Netto, R. Buyya, "Big Data Computing and Clouds: Challenges, Solutions, and Future Directions", arxiv: , December 2013.