by Angela Guess
In a recent post, Craig Borysowich, a Chief Technology Tactician, gives an introduction to data modeling: “In Entity Relationship modeling, the data modeler (together with other project participants) has concentrated on modeling the entities, the ‘things of interest’ to the department, and at the same time, identifying the attributes. It is the attributes of the entities, which are the subject of data modeling. In data modeling these attributes are arranged into a logical data model according to rules described in the following sub-sections. Where previous projects have fully analyzed data requirements, the data modeler may find that the modeling process involves both attributes (in less well defined areas) and data elements (in fully defined areas).”
Borysowich moves into a discussion of attributes and data elements, stating, “After conducting an Entity Relationship modeling exercise, there is a list of attributes associated with each entity. Where an attribute has been identified as representing an important fact regarding an entity, that attribute will eventually be represented by one or more data elements in the eventual database structure. Attributes have a ‘looser’ description than data elements; they could be considered as ‘prototype’ data elements. For instance, whereas an attribute may have only a descriptive name, a data element needs: a size and range, a format and length, an accurate and detailed description, defined edit rules.”
In Borysowich’s view, “The purpose of data modeling is to structure data elements into groups which satisfy user requirements while maintaining maximum flexibility. The resultant logical data model is the baseline for developing a physical database design. The process of data modeling arranges together those data elements which can be uniquely identified by a given key. There are therefore two steps. First, the analyst gathers ‘userviews’, that is arrangements of data elements, which reflect the way users operate on the data. Userviews actually correspond to Physical Data Flows in the Data Flow Diagrams. Ultimately, within each view candidate keys are identified, as well as those data elements which are dependent on the key, the whole key and nothing but the key. Secondly, groups with a common key are consolidated.”
photo credit: Idaho National Laboratory
