RFID (radio frequency identification) implementation continues apace. Standards for such tasks as handoff between suppliers are arriving, and the bulk of large enterprises are now poised between pilots and basic implementations. The set of leaders now includes not only WalMart and Department of Defense but also Procter & Gamble/Gillette.
Basic implementations use an RFID printer to slap a tag on a product or component during production or on entry into a warehouse, then monitor its progress through a warehouse by periodic pinging using stationary RFID readers. Thus, the core data in RFID implementations -- unique identification of a product -- is always accompanied by semantics, or metadata, or data about data, describing where that product is in a business process, or its physical location. The core data typically never changes; the metadata changes very frequently. To put it another way, RFID is metadata in motion.
Three other characteristics also make RFID data management different:
Because RFID has arrived, and because RFID data management is different from anything that has come before, databases must be retuned or re-architected (by the vendor or the user) to handle the new needs of RFID transactions -- as has happened with data warehousing, content management, and Web data in the recent past. Specifically, enterprise information strategists need to answer two questions:
Note that in the long term, there is a third question about RFID data: how can my organization leverage RFID data most effectively, by itself or in combination with existing data?
RFID architecture: The three-level solution
The appropriate database architecture for an RFID implementation reflects the appropriate overall architecture for that implementation. Real-world implementations are tending toward a three-level overall architecture:
As a result, the database architecture is often double three-tier, in which three client/application/databas
To continue reading for free, register below or login
To read more you must become a member of SearchDataCenter.com
e-server tiers operate at both the local and enterprise level.
The right database for the RFID job
RFID implementers should use the following criteria when choosing databases for the local and enterprise levels:
Existing databases within the enterprise have been optimized for different transaction patterns than RFID affords. Therefore, users should plan to tune the chosen database for RFID transaction patterns.
Leveraging RFID data
Clearly, the major benefits of an RFID database accrue from use of an organization-wide RFID database at the enterprise level -- all that the local warehouse manager can improve is turnover for one warehouse.
In the long term, RFID infrastructure software -- including an RFID database -- can deliver positive bottom-line impact. RFID infrastructure software allows greater control over the supply chain, and therefore greater optimization for bottom-line expense-cutting. RFID infrastructure software ensures that RFID delivers a large amount of new actionable information to the corporate decision-maker, potentially both at the retail level (how does product placement on the shelves relate to buying behavior?) and at the production and distribution levels (are we forcing product on a vendor further down the chain?). In fact, RFID data, when enhanced by RFID-infrastructure-software semantics, can provide a source of customer satisfaction, allowing buyers to monitor shipment more closely across the supply chain.
To achieve this, RFID users should emphasize the analytic capabilities of their RFID database, either via BI tools or OLAP. Moreover, RFID implementers need to create a global metadata repository that captures the relationships between the RFID product-process data and existing customer and product data. An EII tool is effective at doing this; or if higher performance is needed, a new data mart may be created. It less likely that inserting RFID data in the organization's existing data warehouse will do the trick, as RFID data is only semi-structured, and the likely large size of the RFID data store may overburden an already-stretched data warehouse.
State of the art
How close are we to achieving an RFID architecture that can handle a flood of metadata in motion?
One easy way to tell is to examine the offerings of today's RFID infrastructure-software suppliers. These are the first line of defense against arriving RFID data ─ they offer at least the buffer level of RFID-data filtering and cleansing. Therefore, they are the minimum software necessary to handle a slap and ship implementation of RFID that requires at least one read from an RFID reader for each widget shipped. Since slap and ship is as far as most RFID implementers have gotten, these RFID infrastructure suppliers' offerings give a good indication of how far we have gotten towards achieving a good RFID data architecture.
As Table 1 shows, these suppliers depend on third parties or the user to design an RFID architecture for handling a flood of data at the local or business level. All depend primarily on third-party data connectivity for EAI (Enterprise Application Integration) and on third-party databases of the user's choice. In effect, it is up to the implementer (with some assistance from service providers) to choose the right databases and software for an RFID architecture and integrate them.
Table 1: RFID unfrastructure-software vendor data architectures
[TABLE] Source: Infostructure Associates, March 2006
How DB2 can help
DB2 holds promise as a global metadata repository, and as a well-integrated data mart. Also, DB2 Express is an attractive candidate for a local-level database.
As noted in a previous article, DB2 can be a highly effective way to implement a metadata repository. Its scalability, robustness, and long experience with data dictionaries (per-database metadata repositories) make it a logical choice. DB2 has long demonstrated scalability in TPC-D benchmarks (aimed at measuring database querying prowess). Its ability to store data in XML format and perform operations on that data, combined with this querying performance, suggests good performance in queries on process-flow metadata.
DB2 has also proven itself as a data mart, as evidenced again by its scalability in TPC-D benchmarks and in real-world data warehousing.
DB2 Express is attractive as a local-level database because of its ability to handle systems management, workflow-semantics data, and querying. Also, as part of the DB2 family it connects well to enterprise-level DB2, and its particular strengths are as an embedded database on top of which users can create warehouse-level applications.
Conclusions
We conclude that:
We would also urge that both suppliers and users turn their attention to data management as a key to long-term RFID success -- or failure. As Robert Reich notes in his book, "The Future of Success," this is an era in which the consumer has unprecedented power to demand satisfaction from his or her suppliers. RFID is the frontier of those demands: it can allow the consumer visibility into the status of his or her order across the supply chain, creates expectations of swifter delivery and less under-stocking, and connects POS data analysis to data on "physically close" inventory for possible "just in time" delivery. However, none of this will be possible without effective data management.
An old ad for Dunkin Donuts has the store manager drag himself out of bed early in the morning, groaning "Time to make the doughnuts." In the same spirit, we advise readers that, yes, it is time to redesign the database and data architecture for RFID -- and to consider DB2 when they do so.
