System Concepts for Data Modeling Essay Example

is about identifying the crucial business and system entities as well as their relationships that represent the scope of the problem that the system will address. These imperative business and system entities are illustrated using the UML profile's modeling elements for business modeling contained in the Business Analysis Model, as well as the Analysis Class model elements from the Analysis Model.

The logical phase entails the precision enhancement of the conceptual high-level business and system bodies into more in-depth logical bodies. These logical bodies and their interrelationships can be optionally outlined in a Logical Data Model using the UML profile's modeling elements for database design as indicated in Guidelines: Data Model. This optional Logical Data Model forms a part of the Artifact: Data Model and is not an independent RUP artifact. * Physical - this phase includes transforming the logical class designs into thorough and optimized physical database table designs.

The physical design phase also consists of connecting the schema of database tables to table spaces and with the database unit in the data storage structure. Moving onto Next Generation Information Systems (NGISs), they are required to aid in the alteration of data centric, behavioral and inferential elements of specific application domains. Several modeling techniques like UML and various object-oriented modeling techniques provide primitives for data-oriented and behavioral aspects, however, they lack in supporting the modeling of deductive elements (Niemi, Junkkari, & Jarvelin, 2002).

Moreover, different independent software/database systems, which are paradigm-based, might implement NGISs. Hence, using a modeling approach based on a single paradigm is unsuitable. The concepts of object orientation are interpretations of diverse entities and occurrences within a specific problem area. Within a business setting,

categories such as customers, sales, employees, inventory, and projects can each represent an object class (Murthy & Wiggins, 1993). A class embodies a collection of like objects.

Objects are simply instances of a specific object class, comprehending all attributes and methods that have been formulated for the particular class. According to modeling viewpoint, the whole problem domain is perceived as an assembly of class hierarchies, specifically of objects, linked through messages exchanged among these objects (Murthy & Wiggins, 1993). The concept of inheritance lends itself to the creation of such class hierarchies. Within such a hierarchy, a subclass takes on all data definitions and methods that the superclass has defined, but it can also possess its own distinctive attributes and methods (Murthy & Wiggins, 1993).

For instance, one can specify an asset object class encompassing generic attributes and functions applicable to all assets, as pointed out by Murthy & Wiggins in 1993. Following this, subclasses for current and fixed assets could be established that would carry over the characteristics and functions from the general object class, while also having their own distinctive properties and functions. Data-model driven design, which forms the basis of Reengineering Systems through Data Models, utilizes two information models.

The Product Model (PM), the first model, is a digital depiction of the product's progression through its life cycle, as stated by ( (Borja, Harding, ; Bell, 2001)via Krause et al. 993). It facilitates the merging of various software applications by creating a single, shared database of product information. The structure and contents of these product models are determined by Product Data Models (PDMs), which are generally applicable in specific areas. The second model of information

is the Manufacturing Model (MM), mentioned earlier. This provides data, information and knowledge about a certain facility's manufacturing potential in relation to its manufacturing resources, processes and strategies.