LESSON-1 DATABASE TERMINOLOGY REVIEW (Cont’d; Ashraf, Khan, and Mir)
LESSON-1 DATABASE TERMINOLOGY REVIEW (Cont’d OBJECT- ORIENTED RELATIONAL MODELLING E-MONOGRAPH By J. Ashraf, M. Khan, and H. Mir)
1.1 Quick Review
What is Data?
The deployment of the word ‘data elements’ are perpetually confronting every day.
To architect a viable storage of ‘data elements’; create, manage, integrate, and maneuvering functionalities without knowledge of basic values, shapes, and sizes and understanding its syntax and semantics, significance and security aspects are worthless. Thus;
Data is unit of readable language and carries no meaning without context
‘Data element’ (data values) imparts meaning corresponding to an atomic field of data storage.
Information is purposeful interpretation of data.
Fact consists of basic nature of information made of data values.
Knowledge is information associated with the rules.
What is a Database?
It is a collection of logically related facts (consists of meaningful data values), designed to meet the information needs of multiple users in an environment. Characteristically, there are various database architectures and database management system (DBMS), these in brief are dealt here under;
1.2 Basic Database Architectures: legacy to stat-of-the art
Hierarchical database model: in this model, files are arranged in top down structure like tree architecture as root and leaves. Data are nested in one-to-many set of relationships. See Figure below;
Network Database Model: in this model, files may be associated with an arbitrary number of files (hierarchy is a special case of network). Its implementation uses pointers between related records in files, which create issues of programming, maintenance, and storage accessibility overheads. See Figure below;
Relational database model: in this model, table data structures are used for storing business facts in entity (of facts). The set of tables of an application is identified in parent child relationship. The table designing was strictly under the normalization rules. Incorporation of variant data structures has no room to play except what tools have provided. The data values are maintained within the acceptability of integrity or rules of business. The data values are the result of processing business transactions, which cause insert/ delete/ update affects of data values. See figure below;
The normalized database designs are often most appropriate for online transaction process (OLTP) applications, since the separation of data into related atomic sets supports a large number of transactions from a large and disparate set of users. In interacting with this kind of database, the focus is on the continual manipulation of data at the level of a single row.
Object-oriented database model: In this model, classes are used which consists of attributes characteristics and methods that operate on these attributes for insert/ delete/ update and query, these components are encapsulated in structures. These classes and subclasses are related in inheritance relationship (like taxonomic framework). For implementation of storing these class instances is called another layer ‘object instances’, bymeans of files (using appropriate data structures) or tables which are not essentially the relational tables.
Multi-dimensional database model: This model is used in data-mart and data-ware housing applications. Two ways are viewing this model existence.
The first view categorizes data as multi-dimensional table in which cell contains one or more simple attributes and the dimensions are always to categorize the raw data. These depend on the factors on which users want to summarize or segment the data for certain needs.
The second view is schema based; the central table contains raw attributes and the composite key made by primary keys of surrounding dimensions of the table.
While discussing how object-oriented models fit into data modeling of relational databases, we are focusing on how object-oriented models document the business subject matter and its processes as yardstick to relational models.
Certain experts define a data-mart and data-warehouse as a query-able source of data. Often it is said, “The data warehouse is nothing more than the union of all the constituent data marts”. Some enterprises perceive data marts to be the building blocks of their data warehouse. Data marts characteristically have:
Possess a Dimensional model design.
Accessed by OLAP tools or an OLAP application.
Hold a single point-in-time snapshot of data.
Periodically refreshed from a source system (a data warehouse).
Data warehouses characteristically have:
Either a Dimensional model design or a normalized design.
Infrequently accessed by any process.
Contain a time variant and historical view of the data.
Periodically refreshed from a source system.
Have dependent data marts.
Problems in performance often arise when attempting to use highly normalized databases for online analytical processing (OLAP) systems. OLAP systems address issues of business analysis, business intelligence, and decision support. They focus on analyzing large amounts of data, generating aggregate statistics, creating ad hoc queries to investigate the details behind these statistics, and identifying historical data trends over time.
These analytical databases often need to perform operations on hundreds, thousands, or millions of rows at a time. Although strictly normalized structures ensure absolute data integrity, attempting to quickly retrieve and process large quantities of data from multiple tables within a normalized database design requires query complexity that can often overwhelm your hardware. The result is query performance poorer.
Dimensional modeling systematically is de-normalizing to optimize the Physical relational model to enhance analytical and ad hoc query operation on large data.
For illustration; Creating a Game Mart may encompass; Game facts, Game dimension, Player dimension, Time dimension, Game move dimension, many more.
Object Oriented Relational Databases: It is embedding of object orientation in relational databases and an integration of relational paradigm into object paradigm. At this stage in brief we need to know, UML? UML is Unified Modeling language as a single system for modeling and documenting information system and business processes, based on object oriented analysis and design philosophy.
UML is not just a replacement of E-R. The parts of UML deal with modeling of; Class diagram, Object diagram, Use case diagram, Sequence diagram, Collaboration diagram, State-chart diagram, Activity diagram, and Implementation diagram.
UML object models are often referred to as class Diagrams, where classes encapsulate the data and behavior of the relevant business objects. Objects always combine data and behavior.
UML Structural Diagrams – are Syntactical Diagrams: Their Logical Modeling with Object addition contains as under;
Class diagram: is a data modeling diagramming language, and similar in Scope in E-R modelling.
Object diagram: represents relationships between system objects. This is a class diagram for only one set of objects while in data model you show example data rather than the data model (useful in understanding complex diagram).
Component diagram: Physical software and hardware component dependencies and organization.
Deployment diagram (Implementation Diagram): Physical system runtime architecture, which can include hardware and software components of the system, as such there are several ways to implement relational categories (rolled-up, rolled-down, extended solution).
UML BEHAVIOR DIAGRAMS (Semantic Diagrams): Describing behavior of business processes.
Use case diagram (behavior diagram): Business processes are implemented where people interact with them. Mainly shows interaction among actors (customers, employees) and use cases. There is no analogue of it in Oracle’s methodology except “function” in Oracle’s Case Method.
Sequence diagram (behavior diagram): The details of specific sequencing of message sent between objects in the system to Elaborating, interaction of objects in a time sequence in order to perform some function. It is similar to process flow diagrammer in relational tools (Oracle Designer).
Collaboration diagram: The details of how individual objects collaborate and interact, consists of objects and messages passed between to perform functions.
State-chart diagram: The details surrounding the transition of objects from one business state to another, these are the state transition diagrams. There is no analogue to this in relational tools (Oracle’s methodology).
Activity diagram: System activities or business processes and the workflows that connect these processes. It is like flow chart that represents operation and decision points, similar to data flow diagram in relational tools (Oracle Designer).
1.3 Role Of Modeling in Software Development
Basically the business requirements are transformed into the development software applications. The business requirements are often complex in characteristics. Interpretation of the requirements, face quality and production problem. The development is a framework of a life cycle.
In addition, there is a difficulty of Implementing and managing changes, which must be understood, developed and integrated into existing systems. Other constraints timeliness of the development incorporated changes.
*****
Click To MAIN PAGE: OBJECT- ORIENTED RELATIONAL MODELLING E-MONOGRAPH, By J. Ashraf, M. Khan, and H. Mir
Click TO NEXT: LESSON-2 DATABASE ARCHITECTURES Click (Cont’d; Ashraf, Khan, and Mir)
*****
- MESSAGE: DEDICATED TO ANONYMOUS COMBATANTS OF KNOWLEDGEمکتب علم الل مہد منل لحد Learning continues from birth to deathFOR PROMOTION OF LEARNEDNESS SHARE WITH FRIENDS ABOUT;
No comments:
Post a Comment