IDEF1x standard is developed for work with relational data bases. In particular IDEF1x standard is meant for constructing of conceptual schemes which represent the structure of data in the context of the concerned system, for example, a commercial organization. IDEF1x standard is a static method and is not intended for dynamic analysis, but it can be used for this, as an alternative to IDEF1 standard.
It is necessary to remember that IDEF1x standard is developed specially for construction of data base structure and that for work it requires an entering of definite data which is not necessary for work with other objects. For example, it requires an entering of dominant attributes to distinguish entities, which is not necessary in the object-oriented projection, so for such projection it is better to use the corresponding IDEF4 standard.
In general the terminology of IDEF1x standard coincides with the terminology of IDEF1 standard, however there are some differences. In IDEF1x the entity is a totality of objects of the real world similar by key properties. Each concrete object in this case is a realization of this entity. For instance an entity COMPUTER represents the totality of all computers of an organization. Each copy of the COMPUTER entity must contain definite information such as computer ID, the name in the network, characteristics, etc. This information is called attributes of an entity.
In IDEF1x entities are connected between each other with links, ties and associations. Ties are called in the verb form. Names of ties show entities relations. For example an ORGANIZATION COMPUTERS, AUTOMOBILE food stuffs, etc.
The first entity in the above mentioned examples is connected with several entities of the second type therefore such tie is called ‘one to many’. At that, the first entity is called parental, and subsequent are daughters. (Child?) On the diagram ties are represented in the form of lines with the dot at the end and with the name specification. Also there are ties of the type ‘many to many’. They are used at the starting stage of the projection and represented in the form of lines with dots at both ends. As an example of such tie is the tie between the mass of PASSNGERS which by a number of BUSES. In future such ties must be necessarily elaborated in details.
Accordingly to IDEF1x standard entities are represented in the form of rectangles with definite fields. At the upper part of the rectangle the key information of the entity, also called the primary key, is located. This information is selected for unique entity identification, e.g. ID of a computer.
At the lower part an area with non key attributes is located, e.g. the name of the computer in the network, the current worker, who works with the computer, works fulfilled on the given computer and computer characteristics.
At the left bottom part an area with the entity name on the diagram is located, e.g. COMPUTER, WORKER or DEPARTMENT.
In the capacity of key attributes several attributes or even attribute groups can be chosen. Attributes, which can be key attributes, are called candidates of key attributes. Key attributes selection rules consist in the following:
- Key attributes must uniquely identify an entity;
- Key attributes mustn’t contain empty or NULL values;
- Key attributes can’t change with time. At key attributes change the entity changes also;
- Key attributes must be brief as far as possible for convenience of the further processing or indexation. For instance these can be alphanumeric symbols of the entity ID.
At choice of the primary key it is often used the so-called surrogate key, which represents an arbitrary number, existing only within the limits of the concrete data base and is unique for each
If entities on the IDEF1x diagram are connected one to each other, then the parent entity transfers key attributes to a child entity. Such attributes are called migratory or external keys. For example, COMPUTER which is on DEPARTMENT balance will have as an external key one of its key attributes the DEPARTMENT ID. Such child entities are called dependent as their identification depends on the key attributes of the parent entity. Dependent entities are divided into those entities which cannot exist without parent entity and those that can’t be identified without parent entity. For example, the INFORMATION on the COMPUTER cannot exist without it or without an external carrier, which are parent entities for it. In its turn, COMPUTER can exist without a DEPARTMENT, but accordingly to the accepted notations, cannot be identified not being the part of any department. Independent entities are those which are not dependent in identification on other entities. These are entities into which the system is divided in the first place and further structuring will happen within the limits of these entities. For example as a rule an organization is divided into DEPARTMENTS which are independent entities as they have its unique identifier not dependent on other entities. All other entities in their identification will depend on ID of the department they belong to.
Accordingly to IDEF1x standard, dependent entities are represented in the form of rounded rectangles, and non-dependent – in the form of usual rectangles.
The ties between entities can be identifying (transferring the external key to a child entity) and non-identifying (transferring data to the area of child entity data). Identifying ties are represented with a solid line, and non-identifying- with dotted line. As an example of identifying tie can be the tie between the DEPARTMENT and any of the resources, which is allotted between DEPARTMENTS and belong not to any of the DEPARTMENTS but to the organization as a whole.
The main advantage of the IDEF1X is the rigid and strict standardization of modeling. Such standardization allows to avoid misunderstandings during the analysis of the constructed model which is the significant advantage against other modeling methods without data bases.
TEN RELATED HOW TO's:
The Process Flowchart or Process Flowchart Diagram (PFD) is a visual representation relations between major parts of the system, the steps in a process, and even connections between various systems. The possibility to easy create professional-looking and attractive Process Flowcharts, Business Process Diagrams and Maps which visualize the steps of complex processes is provided by Business Process Diagram Solution from the Business Processes Area of ConceptDraw Solution Park and 16 libraries with 230 process flowchart symbols from BPMN 1.2 and BPMN 2.0.
Picture: Process Flowchart Symbols
Value Stream & Process Flow Diagramming Software is a very popular Lean Manufacturing tool that allows to see and visualize in details the company's processes and current state, the flow of material and information, and thus gives the possibility to analyze the efficiency of company's processes and then develop improved processes. Value stream maps are also a good way to define the steps that do not add value to the end product, in other words waste in a company's processes.
Picture: Value Stream & Process Flow Diagramming Software
Data flow diagrams are the graphical tool, used in the visualization of data flow of some data processing systems. It is the valuable process modeling tool. Also designing DFD is the important component of the initial part of any information system development project. The standard symbols are used to represent the interaction of a system components and how various kinds of components influence on data flow. The ConceptDraw Data Flow Diagrams solution is design to assist professional software engineers in making DFDs according to Gane and Sarson, and Yourdon and Coad notations.
Do you imagine yourself as a successful IT specialist? To your mind, they all use data flow diagram examples to learn and to get inspired. Aren’t you still with us?
Picture: Data Flow Diagram Examples
Any business process consists from a number of tasks carrying out the certain business goal. It is useful to diagram business processes to ensure that they are as foolproof, logical and sequential as possible. This business process diagram describes a typical booking process flow by the example of a cab booking process. It can be used as a roadmap for any booking system implementation. Diagramming a business process allows you to look at the entire project and take into account all types of possible scenarios. Business process diagram helps you investigate and clarify the process thoroughly so that you can find out how it can be improved. Business process diagram supports team communications by ensuring that each process element is clear and everyone in the team is on the same page.
Sometimes your company brings you less profit than you expect it to be, and it’s difficult to reveal the causes. Maybe it’s time to learn new technologies, because business diagram are easily developed by means of special software, so you won’t make any extra effort. In return, you will increase your productivity and get more done in a less time.
Picture: Business Diagram Software
ConceptDraw DIAGRAM is the world’s premier cross-platform business-diagramming tool. Many, who are looking for an alternative to Visio, are pleasantly surprised with how well they can integrate ConceptDraw DIAGRAM into their existing processes. With tens of thousands of template objects, and an easy method for importing vital custom objects from existing Visio documents, ConceptDraw DIAGRAM is a powerful tool for making extremely detailed diagrams, quickly and easily.
Picture: ConceptDraw DIAGRAM : Able to Leap Tall Buildings in a Single Bound
There are many ways to describe a database structure. One of the most usual is to draw an entity relationship diagram (ERD) using a Crow’s Foot notation to represent database elements. If you don’t want to draw it on paper, you should use an appropriate software.
An entity-relationship (ER) diagram is used to show the structure of a business database. ERD represents data as objects (entities) that are connected with standard relationships symbols which Illustrate an association between entities. ERD, there is a wide range of ERD notations used by data bases architects for reflecting the relationships between the data entities. According to the crow’s foot notation relationships are drawn as single labeled lines designating a certain kinds of relationship. Crow foot notation is a most frequently used ERD standard, because of improved readability of diagrams, with a more accurate use of space on the page.
Picture: Entity Relationship Diagram - ERD - Software for Design Crows Foot ER Diagrams
Structured-systems analysis and design method uses data flow diagrams to represent the process of data flowing through a system. Talking about this might be useless without a proper example of DFD for online store (Data Flow Diagram). This DFD example shows all the distinctness that a diagram can bring into a scattered data structure.
Data flow diagrams are used to show how data is processed within some business processes. Making DFD is a common practice for business process modeling and analysis. This diagram represents the online store business flow. It describes inputs and outputs within online selling process and depicts the interactions between its participants. This DF diagram can be used by system analysts to create an overview of a business, to study and discover its inherent strengths and weak points.
Picture: Example of DFD for Online Store (Data Flow Diagram)