Transform and Restore Pairs
Before data is transferred or stored on some support, it is often converted into an intermediate format. To retrieve data in its original format, a complementary restoring operation is applied, which removes the additional elements and transformations performed by the first kind of operation. Here are the most common pairs of such operations, the first using a data transformation, which changes are rolled-back by a second complementary operation, to restore data to its previous content and format.
One such pair of complementary operations is compilation and disassembling of an executable file. Generally speaking, compilation translates data from source code into machine executable code, or other binary intermediate format. Disassembling does what is commonly known as reverse engineering, in the sense it tries to restore data to its original source code or equivalent format.
Another common pair is backup and restore. Backup archives data, for recovering purpose in case of disaster. Full backup will pack all your data into a backup storage unit. Incremental backups detect and record only those changes since your previous backup. Restoration will rebuilt original data from a sequence of full and incremental backups.
Split and merge algorithms are commonly used to chop data into smaller pieces, store them or send them over a network, eventually using several processors for the parts, then reconstructing the original piece from the parts with a merge operation.
Data can be also automatically split by the operating system during a storing operation. For instance, most operating systems use file systems with data allocated in clusters. Accumulated unused left parts of a clusters can lead to fragmentation and waste of disk space. Fragmentation and defragmentation of data, to lead to more compact storage, are also complementary operations, which change only the way data is stored, but do not alter its content.
Data can be compressed into an intermediate format, to take less space when stored on disk or before transfer over a network, and decompressed at the back-end. Compression-decompression also involve pack and unpack. Packing is the process of grouping together, in one single unit, smaller parts, and can be performed with or without compression or other additional operations.
Network environments do not always support data the way it is presented at a back-end. For instance, TCP/IP works only with ASCII text, binary data not being supported. When data is transferred using a TCP/IP protocol, it needs some kind of encoding, a decoding reverse operation at the other end restoring data at its initial content and format. Depending on the protocol used, it's worth mentioning at least two commonly used encode-decode pairs of methods for HTTP: HTML Encode/Decode, and URL Encode/Decode. Web images can be also translated from binary into an intermediate MIME text format.
For security, data can be encrypted, with an encryption algorithm and additional authentication data. At the other end, the decryption algorithm must know both the kind of encryption used and the additional embedded data for authentication, which will be removed.
From all these pairs of complementary methods, our data extraction magazine is more concerned with and will focus on the restore kind of operation.
Model Translations
At the Presentation level, there may be transformations that simply enrich data with different colors, fonts and layout formats, for better visual distinction between kinds of data. Syntax highlighters are common today, to assign to keywords, tags and values different colors.
While the way data is structured became more and more complex, we need today better tools to represent object models. This object-oriented approach simplifies a lot our understanding about information and relationships. And most applications internally deal with translations from one kind of model to another.
Take for instance the Client-Server layered architecture presented before. It is a separation between a Data layer and Business Logic layer simply because data is usually not stored in the business format, the one you need to finally expose to the end-user at the Presentation layer. Between Data and Logic layers there is what we call a Model Translation. The Data layer may have data organized in a relational manner, represented by an Entity-Relational model well-suitable to the relational database support.
But are these model translations supposed to disappear once we'll be able to use only object-oriented databases? Not necessarily. Data translations and transformations are also necessary for intermediate operations you may need to perform on sets of data, before exposing it to the end user. And same structure of data must be able to be exposed to the end-user in different ways.
Take for instance the Top Rated Movies table, presented at Yahoo!Movies. After scraping that table from the HTML page with a web crawler, data can be presented now as a simplified list or in many other layout formats.
There are also standards for stored metadata information, which may not immediately translate into the way you want your end-user diagrams to look like. For instance, your object-oriented C# classes may generate a UML diagram, but in other cases you just want to show simple relationships between entities, regardless of their type and their kind of association. A use case of such simplified model is when you need a navigational drill-down hierarchies, with parent-child nodes, each linked to a specific metadata kind of object.
Subscribe and Share: 
