Entity Relationship Stored Procedure Meta Language
Total Page:16
File Type:pdf, Size:1020Kb
Proceedings of the 7th WSEAS International Conference on Applied Informatics and Communications, Athens, Greece, August 24-26, 2007 263 Entity Relationship Stored Procedure Meta Language Calin-Adrian˘ Comes, Ioan Rus Nicolae Ghis¸oiu, Paul Vasile Bres¸felean Petru Maior University Babes¸-Bolyai University Financial-Accounting Department, IT Applied for Economics Department, Nicolae Iorga 1, 540088, Mihail Kogalniceanu˘ 1, 400084, Targu-Mures¸,ˆ Mures¸county, Romaniaˆ Cluj-Napoca, Cluj county, Romaniaˆ [email protected], [email protected] [email protected], [email protected] Abstract Model there are a lot confusions regarding the definition of the entity. Bernhard Thalheim in [23] cite more than twelve ER-SPML (Entity Relationship-Stored Procedures Meta different approach for defining the entity notion with the Language) is proposed to be independent by RDBMS team following remark ”The confusion is almost since most of players in idea to support their own SQL dialects on Plat- the database and software engineering books do not define form Specific Language, versus the conceptual level Plat- at all the notion of entity ”. form Independent Language. The metalanguage proposes a OCL [15, 17] was formally developed as a business lan- new operation called Stored Procedures and the language guage with roots in Syntropy, second generation language behind him in idea to be platform independent in relation object-oriented analysis and software design method devel- with SQL dialects and their Procedural Languages. The oped at Object Designers Limited in the UK during the early concept of stored procedures operation is abstract, helps in 1990s, used to describe UML models. syntactic and semantic modeling, and is required in phys- In this paper we try to present the Entity Relationship- ical implementation. A stored procedures operation along Stored Procedure Meta Language in idea to extend : with his language captures the syntactic and semantics of an Data Definition Language(DDL), Data Manipulation Lan- RDBMS schema in his dynamical evolution, not in a statical guage(DML), and Data Control Language (DCL) in Ob- way like ER diagram. An case study of database design with ject Constraint Language(OCL) style to describe the Entity ER-SPML and description using the metalanguage and the Relationship-Stored Procedure diagrammatical artifacts. diagrammatic technique is given. Key-Words: Entity Relationship - Stored Procedures 2 State of the art of ER Meta models Language(ER-SPL), Entity, Attribute, Relationship, Re- lational Database Management System(RDBMS), Data ER Model has been redefined because of his popu- Definition Language (DDL), Data Manipulation Lan- larity with ER Meta models like EER (Extended Entity guage(DML), Data Control Language(DCL) Relationship)[10] , CSL (Conceptual Schema Language) [4], HERM (Higher-Order Entity Relationship Model) 1 Introduction [23], REMORA [20], and Barker [1]. In 1976, Peter Pin-Shan Chen with ER [5] describe 2.1 Extended Entity Relationship (EER) a model that serves as the foundation of many systems Meta model analysis and design methodologies, repository systems, and CASE tools from commercial software vendors to David W. Embley and Tok Wang Ling in [10] extend the free source world. A preliminary framework for Entity- ER Model with EER Meta-model with the following ap- Relationship model was define later in [6]. proaches: capturing the real world semantic, transform the Any important article from journals and books from re- EER Meta model in to a normalized EER Meta model and spectable publishing houses where the modeling word is a generate normalized relations. key word the ER Model or ER Model flavors are just in Entity-Relationship (ER) models and extended Entity- place. During the time because there is no standard for ER Relationship (EER) models has limitations and problems: Proceedings of the 7th WSEAS International Conference on Applied Informatics and Communications, Athens, Greece, August 24-26, 2007 264 • Entity-Relationship (ER) models and extended Entity- 2.4 REMORA Meta model Relationship (EER) models require designers to distin- guish between attributes and entities. This can cause In [20] the REMORA methodology and an expert design downstream redesign when attributes and entities are tool, that supports the design of information systems, are mismatched. described. • Before the transformation of the ER model to relations The REMORA methodology provides a consistent set of designer work with ER diagrams, but after the trans- models, languages, methods and software tools to design formation they work with relation schemes. These re- and implement large and semantically complex information lations may need normalization. Normalization is done systems. The conceptual models use, there is a more di- through a combination of decomposition and synthesis rect and efficient interaction between the designers and the techniques. users, this allows the definition of the information system conceptual schema. Their approach are to capture the real-world semantics in an improved EER model, transform the EER model to a 2.5 Barker Meta model normalized EER model, and generate normalized relations. The Barker model was introduced by R. Barker in [1] 2.2 A Language for Defining Conceptual and modified slightly by the Oracle TMCorporation . The Schema (CSL) pedantic problem with the Barker model is that one needs to fully understand relational database theory to understand In [4] B. Breutmann, R. Falkenberg and E. why the Barker model is done the way it is. We present the Mauer describe a high level data definition language, Barker model here because the way it unfolds is a bit differ- CSL(Conceptual Schema Language), for defining con- ent from the Chen model. The Chen model focuses on mod- ceptual schemes. The language provides descriptive and eling data, whereas the Barker model adapts the data to the procedural elements, so static aspects and dynamic behav- relational database concurrently with the design. Therefore, ior of data can be described. The proposal CSL provides: the ER design methodology for the Barker model will de- standard types, object types and association types: velop differently from the Chen model. Further, the Barker model does not have some of the conventions used in the • Standard operations are: =, <, >, +, −, ∗ and standard Chen model. The Barker model does not directly use the types are like INTEGER, REAL, CHAR, STRING, concept of composite attributes, multi-valued attributes, or DIGIT weak entities, but rather handles these concepts immedi- ately in light of the relational model. Because the Barker • Within an object type only those characteristics can be model is so close to the relational model to begin with, the described which hold for all objects of a certain type mapping rules are trivial the mapping takes place in the diagram itself. A Barker model uses soft boxes for enti- • The association type definition consists of the unique ties (with the entity name in capital letters), and there is a association type name, the participating object types line separating the entity name from the attributes (and the together with their roles and simple occurrence fre- attribute names are in lowercase letters). A Barker model quencies and the identifier of the association type to- does not place the attributes in ovals (as the Chen model gether with the candidate identifiers. does), but rather lists the attributes below the entity name. All attributes in a Barker model are considered simple or 2.3 HERM (Higher-Order Entity Rela- atomic, as in relational databases. tionship Model) Meta model The model does not have the concept of composite at- tributes. In Barker model, the primary key has a # in front B. Thalheim introduces the Higher-Order Entity Rela- of the name of the attribute. tionship Meta model in [23, 24], called HERM, provid- A primary key has to be a mandatory attribute in a rela- ing an interesting conceptual data model, but it is strictly tional database, but again, all mandatory attributes here are founded in theory. not necessarily unique identifiers. In the Barker model, a The Higher-Order Entity Relationship Model is an ex- relationship is represented by a line that joins two entities tension of the Entity Relationship Model. Schemata in the together. There is no diamond denoting the relationship (as Higher-Order Entity Relationship Model can be mapped au- we saw in the Chen model). The relationship phrase for tomatically to relational database schemata. One key fea- each end of a relationship is placed near the appropriate end ture of the HERM is the nesting of attributes. (entity) in lower case. Proceedings of the 7th WSEAS International Conference on Applied Informatics and Communications, Athens, Greece, August 24-26, 2007 265 2.6 Data Schema Integration Meta model 4 Quality measures and Transformation of conceptual schemes – ANNAPURNA In 1983 many problems of data integration are addressed but not all of them and the whole area of data integration is In the 1980’ties conceptual schemes are recognized and not at a mature stage. accepted as an important tool for the design and evolution of In [2] C. Batini and M. Lenzerini describe a methodol- integrated databases and knowledge-based systems, but the ogy for data schema integration consists of three steps: con- question of quality of conceptual schemes is largely ignored flict analysis, merging and final enrichment and restructur- by researchers. In relational database theory quality is de- ing of the schema. fined by the presence or absence of certain normal forms; In the conflict analysis phase all incoherences should the definition of quality was very restrictive because a con- be detected and solved. The main tasks are naming con- ceptual schema is either good or bad. Quality measures are flicts analysis, resolution of synonymy and homonyms and also ignored, but transformation of conceptual schemes are the modeling compatibility analysis. In the merging phase explored systematically. schemata are merged into a unique draft integrated schema. Christoph F.