World Library  
Flag as Inappropriate
Email this Article

Data modeling

Article Id: WHEBN0000759422
Reproduction Date:

Title: Data modeling  
Author: World Heritage Encyclopedia
Language: English
Subject: Outline of information science, IDEF, Comparison of data modeling tools, Compound key, Data modeling
Collection: Data Modeling
Publisher: World Heritage Encyclopedia
Publication
Date:
 

Data modeling

The data modeling process. The figure illustrates the way data models are developed and used today. A conceptual data model is developed based on the data requirements for the application that is being developed, perhaps in the context of an activity model. The data model will normally consist of entity types, attributes, relationships, integrity rules, and the definitions of those objects. This is then used as the start point for interface or database design.[1]

Data modeling (or modelling) in software engineering is the process of creating a data model for an information system by applying formal data modeling techniques.

Contents

  • Overview 1
  • Data modeling topics 2
    • Data models 2.1
    • Conceptual, logical and physical schemas 2.2
    • Data modeling process 2.3
    • Modeling methodologies 2.4
    • Entity relationship diagrams 2.5
    • Generic data modeling 2.6
    • Semantic data modeling 2.7
    • In HMI/SCADA 2.8
  • See also 3
  • References 4
  • Further reading 5
  • External links 6

Overview

Data modeling is a process used to define and analyze data requirements needed to support the business processes within the scope of corresponding information systems in organizations. Therefore, the process of data modeling involves professional data modellers working closely with business stakeholders, as well as potential users of the information system.

According to Steve Hoberman, data modeling is the process of learning about the data, and the data model is the end result of the data modeling process.[2]

There are three different types of data models produced while progressing from requirements to the actual database to be used for the information system.[3] The data requirements are initially recorded as a

  • Agile/Evolutionary Data Modeling
  • Data modeling articles
  • Database Modelling in UML
  • Data Modeling 101
  • Semantic data modeling
  • System Development, Methodologies and Modeling Notes on by Tony Drewry
  • Request For Proposal - Information Management Metamodel (IMM) of the Object Management Group
  • Data Modeling is NOT just for DBMS's Part 1 Chris Bradley
  • Data Modeling is NOT just for DBMS's Part 2 Chris Bradley

External links

  • Kent, William, and Steve Hoberman. Data and reality: a timeless perspective on perceiving and managing information in our imprecise world. Technics publications, 2012.
  • John Vincent Carlis, Joseph D. Maguire (2001). Mastering Data Modeling: A User-driven Approach.
  • Alan Chmura, J. Mark Heumann (2005). Logical Data Modeling: What it is and how to Do it.
  • Martin E. Modell (1992). Data Analysis, Data Modeling, and Classification.
  • M. Papazoglou, Stefano Spaccapietra, Zahir Tari (2000). Advances in Object-oriented Data Modeling.
  • G. Lawrence Sanders (1995). Data Modeling
  • Graeme C. Simsion, Graham C. Witt (2005). Data Modeling Essentials'
  • Matthew West (2011) Developing High Quality Data Models

Further reading

  1. ^ a b c d e f Matthew West and Julian Fowler (1999). Developing High Quality Data Models. The European Process Industries STEP Technical Liaison Executive (EPISTLE).
  2. ^ "Data Modeling for MongoDB Print Version -". technicspub.com. Retrieved May 13, 2015. 
  3. ^ a b Simsion, Graeme. C. & Witt, Graham. C. (2005).Data Modeling Essentials.3rd Edition. Morgan Kauffman Publishers. ISBN 0-12-644551-6
  4. ^ Data Integration Glossary, U.S. Department of Transportation, August 2001.
  5. ^ a b c Whitten, Jeffrey L.; Lonnie D. Bentley, Kevin C. Dittman. (2004). Systems Analysis and Design Methods. 6th edition. ISBN 0-256-19906-X.
  6. ^ American National Standards Institute. 1975. ANSI/X3/SPARC Study Group on Data Base Management Systems; Interim Report. FDT (Bulletin of ACM SIGMOD) 7:2.
  7. ^ a b Paul R. Smith & Richard Sarfaty (1993). Creating a strategic plan for configuration management using Computer Aided Software Engineering (CASE) tools. Paper For 1993 National DOE/Contractors and Facilities CAD/CAE User's Group.
  8. ^ a b c d Len Silverston, W.H.Inmon, Kent Graziano (2007). The Data Model Resource Book. Wiley, 1997. ISBN 0-471-15364-8. Reviewed by Van Scott on tdan.com. Accessed November 1, 2008.
  9. ^ a b c d FIPS Publication 184 released of IDEF1X by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST). December 21, 1993.
  10. ^ Amnon Shabo (2006). Clinical genomics data standards for pharmacogenetics and pharmacogenomics.
  11. ^ "Semantic data modeling" In: Metaclasses and Their Application. Book Series Lecture Notes in Computer Science. Publisher Springer Berlin / Heidelberg. Volume Volume 943/1995.
  12. ^ Rich Hunzinger. "All About SCADA - Data Modeling - Building a Smarter, More Organized SCADA System". b-scada.com. Retrieved May 29, 2015. 
  13. ^ "OPC Unified Architecture - Pioneer of the 4th industrial (r)evolution", chapter on "Integrated address space model"

 This article incorporates public domain material from websites or documents of the National Institute of Standards and Technology.

References

See also

  1. Reduced deployment time of a HMI/SCADA System. Using data modeling, the Data Model and all of the graphics can be created long before any PLC's or OPC Servers are available. All bindings in the graphics are bound to the model not to the live data. This allows design and development of screens ahead of (or in parallel to) the installation of hardware. It also allows graphics designers and others to participate in the design and development of the HMI/SCADA screens without intimate knowledge of the memory addresses of hardware.
  2. Changes to the PLC or OPC Bindings do not affect the HMI/SCADA deployment. If the mapping between the PLC address and the model changes, it does not affect the HMI/SCADA screens (mimics) because they are bound to the model, not the memory addresses. The screens do not need to be republished, compiled or redistributed to the end users.
  3. Screen Reuse for Similar Objects. Hard coding memory addresses on a PLC or OPC Server directly to a graphic requires creation of a graphic for each of asset. Using data modeling, a graphic can be created for a 'type' of asset, allowing the same graphic to be re-used when viewing any asset of that type. For example, creating a single graphic for a wind generator type allows you to view any wind generator in the wind farm with the same graphic . With traditional non-Data Modeled HMI/SCADA applications, a graphic would need to be created for each wind generator.
  4. Functionality well beyond data monitoring. If a memory address is bound to a graphic, the only available data is the value of that memory address. In contrast, data modeled assets become more sophisticated and much more intelligent objects. As an example, a data modeled temperature sensor can have more than just a temperature property — It can have an asset tag, model number, manufacturer, maintenance technician, a troubleshooting manual and maintenance history (and more!). It can have historical performance data and can belong to a logical hierarchy of objects like a storage tank or motor on an assembly line (all of which could also be data modeled objects)[13]

This concept has some significant advantages

Traditional HMI and SCADA products bind data from programmable logic controllers (PLCs) or other data sources directly to the graphics. Data Modeling in HMI/SCADA utilizes a virtualized model of assets in which the HMI/SCADA screens (or other applications) are bound to the Data Model — not the PLC or OPC Server memory addresses. Additional associated information can be added, creating a complete virtualized version of the monitored assets.[12]

A real world application of Data Modeling can be found in Human Machine Interface (HMI) and Supervisory Control and Data Acquisition (SCADA) products such as Schneider's Wonderware Archestra Suite, B-Scada's Status Enterprise and VoT Platform.

In HMI/SCADA

The overall goal of semantic data models is to capture more meaning of data by integrating relational concepts with more powerful abstraction concepts known from the Artificial Intelligence field. The idea is to provide high level modeling primitives as integral part of a data model in order to facilitate the representation of real world situations.[11]

  • planning of data resources
  • building of shareable databases
  • evaluation of vendor software
  • integration of existing databases

A semantic data model can be used to serve many purposes, such as:[9]

Therefore, the need to define data from a conceptual view has led to the development of semantic data modeling techniques. That is, techniques to define the meaning of data within the context of its interrelationships with other data. As illustrated in the figure the real world, in terms of resources, ideas, events, etc., are symbolically defined within physical data stores. A semantic data model is an abstraction which defines how the stored symbols relate to the real world. Thus, the model must be a true representation of the real world.[9]

Semantic data models.[9]

The logical data structure of a DBMS, whether hierarchical, network, or relational, cannot totally satisfy the requirements for a conceptual definition of data because it is limited in scope and biased toward the implementation strategy employed by the DBMS.

Semantic data modeling

Given an extensible list of classes, this allows the classification of any individual thing and to specify part-whole relations for any individual object. By standardization of an extensible list of relation types, a generic data model enables the expression of an unlimited number of kinds of facts and will approach the capabilities of natural languages. Conventional data models, on the other hand, have a fixed and limited domain scope, because the instantiation (usage) of such a model only allows expressions of kinds of facts that are predefined in the model.

Generic data models are generalizations of conventional data models. They define standardized general relation types, together with the kinds of things that may be related by such a relation type. The definition of generic data model is similar to the definition of a natural language. For example, a generic data model may define relation types such as a 'classification relation', being a binary relation between an individual thing and a kind of thing (a class) and a 'part-whole relation', being a binary relation between two things, one with the role of part, the other with the role of whole, regardless the kind of things that are related.

Example of a Generic data model.[10]

Generic data modeling

Several techniques have been developed for the design of data models. While these methodologies guide data modelers in their work, two different people using the same methodology will often come up with very different results. Most notable are:

These models are being used in the first stage of information system design during the requirements analysis to describe information needs or the type of information that is to be stored in a database. The data modeling technique can be used to describe any ontology (i.e. an overview and classifications of used terms and their relationships) for a certain universe of discourse i.e. area of interest.

There are several notations for data modeling. The actual model is frequently called "Entity relationship model", because it depicts data in terms of the entities and relationships described in the data.[5] An entity-relationship model (ERM) is an abstract conceptual representation of structured data. Entity-relationship modeling is a relational schema database modeling method, used in software engineering to produce a type of conceptual data model (or semantic data model) of a system, often a relational database, and its requirements in a top-down fashion.

Example of an IDEF1X Entity relationship diagrams used to model IDEF1X itself. The name of the view is mm. The domain hierarchy and constraints are also given. The constraints are expressed as sentences in the formal theory of the meta model.[9]

Entity relationship diagrams

Sometimes models are created in a mixture of the two methods: by considering the data needs and structure of an application and by consistently referencing a subject-area model. Unfortunately, in many environments the distinction between a logical data model and a physical data model is blurred. In addition, some CASE tools don’t make a distinction between logical and physical data models.[8]

  • Bottom-up models or View Integration models are often the result of a [8]
  • Top-down logical data models, on the other hand, are created in an abstract way by getting information from people who know the subject area. A system may not implement all the entities in a logical model, but the model serves as a reference point or template.[8]

Data models represent information areas of interest. While there are many ways to create data models, according to Len Silverston (1997)[8] only two modeling methodologies stand out, top-down and bottom-up:

Modeling methodologies

[1] In the process, system

The process of designing a database involves producing the previously described three types of schemas - conceptual, logical, and physical. The database design documented in these schemas are converted through a Data Definition Language, which can then be used to generate a database. A fully attributed data model contains detailed attributes (descriptions) for every entity within it. The term "database design" can describe many different parts of the design of an overall database system. Principally, and most correctly, it can be thought of as the logical design of the base data structures used to store the data. In the relational model these are the tables and views. In an object database the entities and relationships map directly to object classes and named relationships. However, the term "database design" could also be used to apply to the overall process of designing, not just the base data structures, but also the forms and queries used as part of the overall database application within the Database Management System or DBMS.

In the context of business process integration (see figure), data modeling complements business process modeling, and ultimately results in database generation.[7]

Data modeling in the context of Business Process Integration.[7]

Data modeling process

According to ANSI, this approach allows the three perspectives to be relatively independent of each other. Storage technology can change without affecting either the logical or the conceptual schema. The table/column structure can change without (necessarily) affecting the conceptual schema. In each case, of course, the structures must remain consistent across all schemas of the same data model.

  • Physical schema: describes the physical means used to store data. This is concerned with partitions, CPUs, tablespaces, and the like.
  • Logical schema: describes the structure of some domain of information. This consists of descriptions of (for example) tables, columns, object-oriented classes, and XML tags. The logical schema and conceptual schema are sometimes implemented as one and the same.[3]

In 1975 ANSI described three kinds of data-model instance:[6]

The ANSI/SPARC three level architecture. This shows that a data model can be an external model (or view), a conceptual model, or a physical model. This is not the only way to look at data models, but it is a useful way, particularly when comparing models.[1]

Conceptual, logical and physical schemas

  • Business rules, specific to how things are done in a particular place, are often fixed in the structure of a data model. This means that small changes in the way business is conducted lead to large changes in computer systems and interfaces. So, business rules need to be implemented in a flexible way that does not result in complicated dependencies, rather the data model should be flexible enough so that changes in the business can be implemented within the data model in a relatively quick and efficient way.
  • Entity types are often not identified, or are identified incorrectly. This can lead to replication of data, data structure and functionality, together with the attendant costs of that duplication in development and maintenance.Therefore, data definitions should be made as explicit and easy to understand as possible to minimize misinterpretation and duplication.
  • Data models for different systems are arbitrarily different. The result of this is that complex interfaces are required between systems that share data. These interfaces can account for between 25-70% of the cost of current systems. Required interfaces should be considered inherently while designing a data model, as a data model on its own would not be usable without interfaces within different systems.
  • Data cannot be shared electronically with customers and suppliers, because the structure and meaning of data has not been standardised. To obtain optimal value from an implemented data model, it is very important to define standards that will ensure that data models will both meet business needs and be consistent.[1]

Data models provide a structure for data used within information systems by providing specific definition and format. If a data model is used consistently across systems then compatibility of data can be achieved. If the same data structures are used to store and access data then different applications can share data seamlessly. The results of this are indicated in the diagram. However, systems and interfaces often cost more than they should, to build, operate, and maintain. They may also constrain the business rather than support it. This may occur when the quality of the data models implemented in systems and interfaces is poor.[1]

How data models deliver benefit.[1]

Data models

Data modeling topics

Data modeling is also used as a technique for detailing business requirements for specific databases. It is sometimes called database modeling because a data model is eventually implemented in a database.[5]

  • Strategic data modeling: This is part of the creation of an information systems strategy, which defines an overall vision and architecture for information systems is defined. Information engineering is a methodology that embraces this approach.
  • Data modeling during systems analysis: In systems analysis logical data models are created as part of the development of new databases.

Data modeling may be performed during various types of projects and in multiple phases of projects. Data models are progressive; there is no such thing as the final data model for a business or application. Instead a data model should be considered a living document that will change in response to a changing business. The data models should ideally be stored in a repository so that they can be retrieved, expanded, and edited over time. Whitten et al. (2004) determined two types of data modeling:[5]

  • to assist business analysts, programmers, testers, manual writers, IT package selectors, engineers, managers, related organizations and clients to understand and use an agreed semi-formal model the concepts of the organization and how they relate to one another
  • to manage data as a resource
  • for the integration of information systems
  • for designing databases/data warehouses (aka data repositories)

Data modeling techniques and methodologies are used to model data in a standard, consistent, predictable manner in order to manage it as a resource. The use of data modeling standards is strongly recommended for all projects requiring a standard means of defining and analyzing data within an organization, e.g., using data modeling:

[4]

This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and USA.gov, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for USA.gov and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
 
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
 
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.
 


Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.