Scribd
Upload
44 views

Fmea - Odbc-Export: Necessary Tables and Their Allocation To FMEA-Objects in The IQ-Fmea

This document describes the necessary tables and structure for exporting FMEA data from an IQ-FMEA database to an ODBC data source. There are 27 tables that are used to store different elements like structures, functions, failures, measures, and their relationships. The export can occur in replacement or deletion mode. Replacement mode updates existing records, while deletion mode clears all tables before inserting new records to keep the ODBC database synchronized with the IQ-FMEA database. Testing has been done exporting to Access, dBASE, FoxPro, text files, and Excel via ODBC.

Uploaded by

Giuseppe Zaccaro
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
44 views

Fmea - Odbc-Export: Necessary Tables and Their Allocation To FMEA-Objects in The IQ-Fmea

This document describes the necessary tables and structure for exporting FMEA data from an IQ-FMEA database to an ODBC data source. There are 27 tables that are used to store different elements like structures, functions, failures, measures, and their relationships. The export can occur in replacement or deletion mode. Replacement mode updates existing records, while deletion mode clears all tables before inserting new records to keep the ODBC database synchronized with the IQ-FMEA database. Testing has been done exporting to Access, dBASE, FoxPro, text files, and Excel via ODBC.

Uploaded by

Giuseppe Zaccaro
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Fmea - Odbc- Export

Necessary tables and their allocation to FMEA-Objects in the IQ-Fmea:

Fmea000 Structures of a Fmea file


Fmea001 All structure elements of the exported structures.
Fmea002 Function Types
Fmea003 Failure Types
Fmea004 C-Measure Types (Control-Measure)
Fmea005 P-Measure Types (Preventive-Measure)
Fmea006 Measure States
Fmea007 Persons
Fmea008 Teams
Fmea009 Structure Tree
Fmea010 Structure Element – Function occurrences
Fmea011 Function events- Failure Occurrences
Fmea012 Measure State - C-Measure Occurrences
Fmea013 Measure State - P-Measure Occurrences
Fmea014 Failure Occurrences- Failure Causes
Fmea015 Function Occurrences – Function Causes
Fmea016 Function Types- Function Occurrences
Fmea017 Failure Types – Failure Occurrences
Fmea018 C-Measure Types - C-Measure Occurrences
Fmea019 P-Measure Types - P-Measure Occurrences
Fmea020 Failure Occurrences - (MeasureChanges)
Fmea021 Measure Changes – Measure States
Fmea022 Teams – Persons
Fmea023 Languages
Fmea024 Information for the existing Formsheets, e. g. Headerdata
Fmea025 Classification of types (functions, failures, measures)
Fmea026 Userdefined Attributes (Name and Translations)
Fmea027 Objekts (UniqKeys) with referenced Userdefined Attributes (UniqKeys)

Table Description
Fieldnames printed in bold are primary key and secondary key of the relative table
respectively.
The field definition is put down only once exemplarily for all identical fieldnames. All
UniqueKey's and all references (named Ref), are declared by text (16). Lkeys are declared
as a number (integer).

Fmea000:
Uniqkey Lkey Name (text) FmeaType (text(16)) Context (text) Root Orphan

Fmea001:
Uniqkey Lkey Name Context Notes (text) Fmea (Ref)

Fmea002:
Uniqkey Lkey Name Category

Fmea003:
Uniqkey Lkey Name Category

Fmea004:
Uniqkey Lkey Name Category
Fmea005:
Uniqkey Lkey Name Category

Fmea006:
Uniqkey Name Mdate (DateTime) Deadline (DateTime) State (Text 32)

Fmea007:
Uniqkey Name Role Deptmnt Address Phone Fax Email
(text) (text) (text) (Text 32) (Text32) (text)

Fmea008:
Uniqkey Name

Fmea009:
Uniqkey Children (Ref)

Fmea010:
Uniqkey Function (Ref)

Fmea011:
Uniqkey Faults (Ref)

Fmea012:
Uniqkey Detect (Ref) Resp (Ref) State (Text 32) Deadline Rate
(DateTime) (int)

Fmea013:
Uniqkey Prevent (Ref) Resp (Ref) State (Text 32) Deadline Rate
(DateTime) (int)

Fmea014:
Uniqkey Causes (Ref)

Fmea015:
Uniqkey Prereqs (Ref)

Fmea016:
Uniqkey Occur (Ref) Context Notes

Fmea017:
Uniqkey Occur (Ref) Signific (int) Kontext Notes

Fmea018:
Uniqkey Occur (Ref) Context Notes

Fmea019:
Uniqkey Occur (Ref) Context Notes

Fmea020:
Uniqkey Revision (Ref)
Fmea021:
Uniqkey Mstate (Ref)

Fmea022:
Uniqkey Persons (Ref)

Fmea023:
Lkey Lang (Text 32)

Fmea024
Uniqkey Field (Text 32) FieldVal (text) Type (Text 16) Kind (Text 16)

Fmea025:
Uniqkey Children (Ref)

Fmea026:
Uniqkey Lkey Name

Fmea027:
Uniqkey udaKey (Ref)

Odbc-Handling
In order to start the Odbc-Export, a fully functional Odbc-Installation is required. Information
about it is provided by the documentation for the corresponding database applications e.g.
MS-Access. When the installation has been successful, a data source has to be installed next.
This is a denotation which can be put into relation with an existing database. The Odbc-setup
can be started from the MS-Windows settings (Control Panel).
After this logical datasource has been declared, you can select it as the destination. During
the export the IQ-Fmea checks if the tables mentioned above are already existent. Non
existent tables are created. Assignment takes place through the mentioned Unique-Identities.
Those are at the same time primary key for the entity-tables 1 – 8. Almost all other tables are
allocation tables. Their key is at a time the combination of both identities of the assignment.
There are two Export-Modes:

1. Replacement:
If records are existing unambiguously, they are replaced in case of modifications to the
original. If the record doesn’t exist yet, it is attached. If it occurs multiple times the method
runs into error-handling. If assignments or other objects are deleted in this mode in the IQ-
Fmea-Database (e.g. deletion of events), the corresponding records stay alive in the odbc-
datasource. This might lead to an inconsistent state of the Odbc-database. Moreover this
state is not fully synchronous to the IQ-Fmea-Database.

2.Deletion:
Independently from the question whether records are existent or not, all Odbc-tables are
deleted in the beginning. Each record is newly generated and added. If all structures of an IQ-
Fmea database are exported there is always a consistent relational representation of this IQ-
Fmea-database guaranteed at the time of the export.

Error-handling
The export runs into error-handling, if a record can’t be added or if a record that shall be
replaced can’t be identified distinctly (see above):

Yes >> all following errors are ignored


No >> the next occurring error is notified again.
Cancel >> same behaviour as No.
Relations between Tables:

First the structures with root-structure element and default-se (that’s the virtual orphan for
unanchored objects) are written into table 000. In table 009 the structure tree is mapped.
Through it, starting from the root-se, the structure elements can be linked back to their
structure.
Starting from the now correctly linked structure elements function occurrences can be linked
back through table 010 and failure occurrences can be linked back through table 011.
Analogue to the measure changes, the measure states and the measures can be handled.
All functions and failures which do not possess any backlink are unanchored. Starting from
Orphan in table 000 you receive the default-Se in table 001. You receive the default function
event through default-se in table 010 and in table 011 the corresponding unanchored failure
events. Through this chain the backlinks can be built up. The assignment of unanchored
objects to their type occurs in the usual manner. Failure nets and function nets are solely
mapped through the causes. Each failure that has another failure as a cause is at the same
time effect of this failure. Through this connection the complete failure net can be built.
Analogue for the functions.
The classification is mapped in table Fmea025. It works solely through the assignment of
identities. In this respect, a differentiation of the individual types is not necessary. All classified
types (function type, failure type, C-measure, P-measure are included in this table.)

multilingualism
Export to all existing database languages. In each entity table (from 1 – 5) a second key
indicates the language in which the entity is written. Consequently, there is only one entry in
the entity table for each entity in a specific language.

Hitherto testing-experience
Odbc-Export-Tests are availabel for
Access 2.0 und Access 95
Dbase 4.0 und 5.0
FoxPro
Text (Note: don’t take csv, but an other seperator instead)
Excel (only for existing worksheets)
notes:

The creation of databases via Odbc works with 16 and 32 bit Odbc. 32 bit plattforms are able
to open and write to 16 bit-created databases, but not the other way round.

You might also like