 |
What is Data Modeling? |
 |
This is the
process of structuring and organizing data. These data structures are
then typically implemented in a database management system. In
addition to defining and organizing the data, data modeling may also
impose constraints or limitations on the data placed within the
structure.
Managing large quantities of structured and unstructured data is a
primary function of information systems. Data models describe
structured data for storage in data management systems such as
relational databases. They typically do not describe unstructured
data, such as word processing documents, email messages, pictures,
digital audio, and video. Early phases of many software development
projects emphasize the design of a conceptual data model. Such a
design can be detailed into a logical data model. In later stages,
this model may be translated into physical data model.Data model
The term data model actually refers to two very different things: a
description of data structure and the way data are organized using,
for example, a database management system.
Data structure
A data model describes the structure of the data within a given domain
and, by implication, the underlying structure of that domain itself.
This means that a data model in fact specifies a dedicated 'grammar'
for a dedicated artificial language for that domain. Because there is
little standardisation of data models, every data model is different.
This means that data that is structured according to one data model is
difficult to integrate with data that is structured according to
another data model. A data model may represent classes of entities
(kinds of things) about which a company wishes to hold information,
the attributes of that information, and relationships among those
entities and (often implicit) relationships among those attributes.
The model describes the organization of the data to some extent
irrespective of how data might be represented in a computer system. |
|
|
The entities represented by a data model can be the tangible entities,
but models that include such concrete entity classes tend to change
over time. Robust data models often identify abstractions of such
entities. For example, a data model might include an entity class
called "Person", representing all the people who interact with an
organization. Such an abstract entity class is typically more
appropriate than ones called "Vendor" or "Employee", which identify
specific roles played by those people.
A proper conceptual data model describes the semantics of a subject
area. It is a collection of assertions about the nature of the
information that is used by one or more organizations. Proper entity
classes are named with natural language words instead of technical
jargon. Likewise, properly named relationships form concrete
assertions about the subject area. For example, a relationship called
"is composed of" that is defined to operate on entity classes "Order"
and "Line item" forms the following concrete assertion definition:
Each "Order" "is composed of" one or more "Line items." Note that
this illustrates that often generic terms, such as "is composed of",
are defined to be limited in their use for a relationship between
specific kinds of things, such as an order and an order line. This
constraint is eliminated in the generic data modeling methodologies.
Generic Data Modeling
Generic data modeling has the following characteristics:
 |
|
 |
| |
 |
A generic data model shall consist of generic entity types,
such as 'individual thing', 'class', 'relationship', and
possibly a number of their subtypes. |
 |
 |
 |
Every individual thing is an instance of a generic entity
called 'individual thing' or one of its subtypes. |
 |
 |
 |
Every individual thing is explicitly classified by a kind of
thing ('class') using an explicit classification relationship. |
 |
 |
 |
The classes used for that classification are separately
defined as standard instances of the entity 'class' or one of
its subtypes, such as 'class of relationship'. These standard
classes are usually called 'reference data'. This means that
domain specific knowledge is captured in those standard
instances and not as entity types. For example, concepts such
as car, wheel, building, ship, and also temperature, length,
etc. are standard instances. But also standard types of
relationship, such as 'is composed of' and 'is involved in'
can be defined as standard instances. |
|
|
 |
|
 |
This way of modeling allows to add standard classes and standard relation
types as data (instances), which makes the data model flexible and
prevents data model changes when the scope of the application changes.
A generic data model obeys to the following rules:
 |
|
 |
| |
 |
1. Candidate attributes are treated as representing
relationships to other entity types. |
 |
 |
 |
2. Entity types are represented, and be named after, the
underlying nature of a thing, not the role it plays in a
particular context. Entity types are chosen |
 |
 |
 |
3. Entities have a local identifier within a database or
exchange file. These should be artificial and managed to be
unique. Relationships are not used as part of the local
identifier. |
 |
 |
 |
4. Activities, relationships and event-effects are represented
by entity types (not attributes). |
 |
 |
 |
5. Entity types are part of a sub-type/super-type hierarchy of
entity types, in order to define a universal context for the
model. As types of relationships are also entity types they
are also arranged in a sub-type/super-type hierarchy of types
of relationship. |
 |
 |
 |
6. Types of relationships are defined on a high (generic)
level, being the highest level where the type of relationship
is still valid. For example, a composition relationship
(indicated by the phrase: 'is composed of') is defined as a
relationship between an 'individual thing' and another
'individual thing' (and not just between e.g. an order and an
order line). This generic level means that the type of
relation may in principle be applied between any individual
thing and any other individual thing. Additional constraints
are defined in the 'reference data', being standard instances
of relationships between kinds of things. |
|
|
 |
|
 |
Data organization
Another kind of data model describes how to organize data using a database
management system or other data management technology. It describes, for
example, relational tables and columns or object-oriented classes and
attributes. Such a data model is sometimes referred to as the physical
data model, but in the original ANSI three schema architecture, it is
called "logical". In that architecture, the physical model describes the
storage media (cylinders, tracks, and tablespaces). Ideally, this model is
derived from the more conceptual data model described above. It may
differ, however, to account for constraints like processing capacity and
usage patterns.
While data analysis is a common term for data modeling, the activity
actually has more in common with the ideas and methods of synthesis
(inferring general concepts from particular instances) than it does
with analysis (identifying component concepts from more general ones). Data modeling strives to bring the data structures
of interest together into a cohesive, inseparable, whole by eliminating
unnecessary data redundancies and by relating data structures with
relationships.
 |
|
 |
| |
|
References |
 |
|
Information is taken in whole, or in part, from
Wikipedia,
The Free Encyclopedia - which is a fully independent knowledge resource
that has no affiliation with Select Business Solution. As a
result, Select Business Solutions takes no responsibility for
the accuracy. If you believe the information is wrong, please
contact us and we will investigate. |
|
|
 |
|
 |
 |
Learn More |
 |
To find out more about how Select Business Solutions can help you
Contact Us today.
|
 |
|