Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Jon R. Oler

dblp:32/4791 · DBLP profile ↗
← Back
1ranked-venue papers
1as first author
0since 2021 · last 1997
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Databases, data mining, and information retrieval
1 paper
Database system architecture and tuning · 100%
Interdisciplinary, comprehensive, and emerging computing
1 paper
Bioinformatics and computational biology · 100%

Topics — the 1 heaviest of 2, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Database system architecture and tuning › database administration
database migration
0.011997
Migrating Relational Data to an OODB: Strategies and Lessons from a Molecular Biology Experience · OOPSLA 1997

Methods — techniques the papers use, named apart from their topics

c++ framework · 0.0
YearPublicationVenuePosition
1997 Migrating Relational Data to an OODB: Strategies and Lessons from a Molecular Biology Experience
abstract
The growing maturity of ODBMS technology is causing many enterprises to consider migrating relational databases to ODBIMS's. While data remapping is relatively straight-forward in most cases, greater challenges lie in economically and non-invasively adapting legacy application software. We report on a genetics laboratory database migration experiment, which was facilitated by both organization of the relational data in object-like form and a C++-framework designed to insulate application code from relational artifacts. Although this experiment was largely successful, we discovered to our surprise that the framework failed to encapsulate three subtle aspects of the relational implementation, thereby ''contaminating'' application code. We analyze the underlying issues, and offer cautionary guidance to future migrators.
Jon R. Oler, Gary Lindstrom, Terence Critchlow
OOPSLA1