Essay:

Essay details:

  • Subject area(s): Engineering
  • Price: Free download
  • Published on: 7th September 2019
  • File format: Text
  • Number of pages: 2

Text preview of this essay:

This page is a preview - download the full version of this essay above.

The Entity-Relationship model (ER) is a way of describing and defining many entity and their attributes. The Articulated Entity Relationship (AER) is an improved model from ER-diagram by  accommodation (FDs) information as an element of (ER) diagram itself  .This paper present FDD as a new methodology for have total and unconditional automation normalization that enhanced from articulated entity relationship AER . FDD aimed to eliminate the complexity of AER diagram with keeping the normalization process done automatically in one go. A new notation added to ER diagram to illustrate FDs and by give a unique number to each attribute to remain the ability of designer to go back to the diagram to read and modify it easily.

1- Introduction

Many commercial organizations depend on its productivity and quality of the production to increase the profits and productivity without effecting on the quality [1]. Thus, it is necessary for organizations to automate the process involve in the design and improvement of their products to accomplish the goals by using relational database.

Relational databases are used in all commercial applications process. Such as, store and modify data [2]. So, relational schema design is very important to the success of relational database.

Relational database design consists of several steps. For instance, drawing entity relationship (ER) diagram, transforming (ER) diagram to database schema, defining (FDs), and normalization. which is the most important step in the design of relational database and that takes a large relation with functional dependencies as input and convert it into set of smaller relations with fewer attributes without redundancy, unambiguous and as intended [2]. From the last few decades normalization carried out manually, which has several drawbacks. For example, it is more complex especially when the number of relations and number of attributes in each relation is large, waste of time, prone to errors, costly and needs experts persons. Therefore, to eliminate the drawbacks of manual normalization many researchers proposed methods to automate normalization process [3].

Articulated Entity Relationship (AER) [3] is proposed recently for a complete automation of normalization. So, normalization carried out in one click without designers intervention. (AER) described functional dependencies (FDs) as a connector between the attributes. Thus, automatic  normalization can be carried out from (ER) diagram up to BCNF[3] .Unfortunately , (AER) has a problems like diagram becomes more difficult , complicated and hard to understand by developer because of accommodation (FDs) information as an element of (ER) diagram itself .

This paper proposed a useful method to avoid (AER) complicating drawback. Add notations to illustrate (FDs) called functional dependencies description (FDD)  and give aunique number to each attribute in entity instead of connectors between attributes to avoid complexity that appeared in the (AER). After that, export the database schema represented by (FDD) diagram to normalization tools in the form of a XMI file, where relations and their (FDs) are retrieved as a XMI file. Thus, the database designer can be easily read, understand and adjustments the (ER) and (FDs) to achieve total and unconditional automation normalization with the help of (FDD) diagram.

2. Related Work

    Articulated Entity Relationship (AER) is one of papers that specialize in automation process of normalization [3]. The AER representation the Functional Dependency (FD) in form of connectors between attributes. Therefore, FD information will be changed if any changes occur in the diagram. Also, AER diagram considered as input to normalization tool which convert database to more normalized forms. Unfortunately, the complexity of the diagram is the main problem in AER methodology. Thus, this paper proposed a new methodology to solve this problem.

Vijay Laxmi, et.al . [14] Used AER diagram to contain the details of FD because it is important part of the automation normalization process.. In addition, FD used as a feature to add, update and delete the attributes.     

Many tools developed for different purpose in DB .For instance, ER Draw [5] proposed a useful tool for drawing ER and translates it to relations by using XML language. This paper will be use this tool to translate FDD. Chetneti Srisa-an [6] Used spanning tree algorithm technique to eliminate multiple candidate keys and determine a primary key for a table. Thus, this tool is very useful when there is a complex FD. Bahmani, A.H, et.al. [7] proposed another algorithm to normalize DB automatically by using dependency matrix. In this tool the attributes translated into matrix and directed graph that used for keeping track of these dependencies and to do automatic normalization up to BCNF. Amir Hassan Bahmani, et. al. [15] proposed a new method to complete automation normalization of the relational DB by organize FD in a matrix. After that, generate the primary key to prepare the ER to 2NF,3NF and BCNF. Patwardhan, M. S.  et.al. [8] suggested Integrated development environment (IDE) as a new tool to help drawing, storage, validate and normalization of the AER diagram.

The simplicity of diagram discussed as important issue to understand the diagram by Helen C. Purchase et.al. [9]. A comparative study of the ER notation was done between two notation (Chen and SSADM entity relationship diagrams) by using a new methodology to determine which of them easy to understand to DB users. Also, there is a target changes on the individual notation. There are presented the results of the best deals on both of them, with the results of partial variables relating to the individual. Thus, it is easy to found an experimental framework to compare between two representations of the notation methodology.

Many works proposed frameworks to extracting the ER diagram from different forms .For example, N. M Fourga proposed a new framework to extract the ER schema from a group of form model that related to operational DB[10] .In another word, reverse engineering of operational DB to ER schema. Another framework of reverse engineering proposed by Dowming Yeh a,et.al. to extract ER from legacy DB[11]. Table schema is used as input to this framework and the output is attributes, primary keys and relationships. V.Consenting, et.al. [12] Proposed a different form of reverse engineering .This framework focused on the extracting of the UML diagram from relational DB with a number of integration and derivation OCL constraint. But, this technique ignores some integrity constraints and rules. So, this technique will be used when UML/OCL model of DB is important. Another approach proposed by Peter pin -shan chen [13] to convert English sentences to ER diagram. In other word convert sentences that contain a description of the entity such as attributes and relationships between them  to ER diagram

.

3. Problems in current approach AER

AER have major drawback.  The diagram becomes too complex. The complexity of diagram makes the develop process by designer is difficult because it is not easy to understand especially when building large and complex systems .Thus,  the designer  waste a lot of time and effort in analyses and understand the diagrams. Figure2(b) shows AER diagram of company system. It focuses on ER and FDs for entity “company system” along with its attributes. In this paper FDD methodology proposed to eliminate AER drawbacks.

4. Overview for the proposed methodology Function dependency Description (FDD) diagram and formal notation

FDD approach is passing through many processes to obtain the goal which is normalized database. The steps involved in automation of normalization FDD approaches are shown in Figure1.

Figure 1. Total and unconditional Automation of Normalization using FDD methodology.

 Total and unconditional automation achieved by using “Function dependency description” (FDD) methodology.. The proposed methodology FDD is called total  since it allows achieving maximum possible automation and called unconditional since it can automate the task without user interaction.

The proposed methodology passing through several processes to obtain normalized DB as shown in Figure 1. FDs are accommodating in FDD diagram and represented using special notation which is contain a numbers of weak entity that determined in each arrow. These notations are added to facilitate the understanding, and to make it easy to convert the diagram to relation. The multiplicity of FDD using to represents any possible FD.XML language used to read and translate FDD diagram to DB schema and FDs. After that, these output import to DB Normalization Tool to achieve the Normalized DB schema. The next subsection explains the proposed

methodology processes in more detail.

5. Function dependency description” (FDD) diagrams and formal notation

 

FDD with added notation are the main inputs for the proposed methodology.FDD diagrams accommodate FD information, as its integral part. FD information in FDD diagram is diagrammatically represented by follows:

1-Give a unique number to each attribute of entity type as Table (1).

Table (1). Attribute number

Index Attribute Attribute number

1 Attribute 1 1

2 Attribute 2 2

3 Attribute 3 3

…… …… ….

n Attribute n n

The number is given to each attribute in systematic method. The first attribute which is located in the left –up corner of entity  is determined and take number (1).  After determined the first attribute the  method give a number to each attribute with clock  by increment (1 ) and so on  until the last one.

2- Add  â€œnotation”. There are types of notation shown in Table (2) to make the process easier to understand.

Table 2.  Notation that added to AER diagram to illustrate FDs

    Notation # Notation name Notation Graphical Representation Description

1. Right Arrow

This notation means  attribute (A) determines one attribute included as a number in arrow.

2. Left-Right Arrow

This notation means attribute (A) determines two attributes included as a numbers in each directions.

3. Left-Right-Up Arrow

This notation means  attribute (A) determines three attributes included as a numbers in three directions.

4. Quad Arrow

                   This notation means attribute (A) determines four attributes included as a numbers in each directions and so on each determined attribute illustrate as arrow.

 Table1. Show four types of notations. These notations added to AER -diagram to achieve the functionality of FDD methodology. The main goal of this paper is make the read and understand of ER and FDs easy to designers and users.

.

5.1Types of notations

Attributes involved in a FD relation can be participating as a determiner attribute  or as a dependant attribute. Both dependants and determiners in a FD can be made up of multiple attributes. Thus, there is a need to connect all the attributes taking participation in a FD as determiner and dependant.  Table (3) shows how FDD illustrate FD if n attributes (where n≥2) determine m attributes (where n≥2).

Table 3. Multiplicity Representation for FDD.

Sr.

No. Multiplicity

Representations Description Graphical Representation

1. 1:1 FDD The FD notation connects one determiner attribute to one dependent attribute.

2. n : 1 FDD The FD notation connects Many (n) determiner attributes to one dependent attribute. Here A1, A2…An are determiner attributes and (1) is a dependant attribute number.

3. 1: m FDD        The FD notation connects one determiner attribute to many (m) dependent attributes. Here A is a determiner attribute and 2Arrow…..n Arrow are dependant attributes numbers.

4. n : m FDD The FD notation connects

Many determiner attributes (n) to many dependent attributes (m), where it is not

necessary that m =n . Here A1 …An are determiner attributes and 2Arrow….n Arrow are dependant attributes  numbers.

...(download the rest of the essay above)

About this essay:

This essay was submitted to us by a student in order to help you with your studies.

If you use part of this page in your own work, you need to provide a citation, as follows:

Essay Sauce, . Available from:< https://www.essaysauce.com/essays/engineering/2015-12-27-1451240485.php > [Accessed 22.10.19].