Welcome!

Java IoT Authors: Carmen Gonzalez, Yeshim Deniz, Elizabeth White, Pat Romanski, Liz McMillan

RSS Feed Item

What Standards for Object Databases?

I thought it would be interested to give you an insight of the discussion currently going on at ODBMS.ORG. The issue is what Standards for Object Databases?
Here are two notes, one from Wiliam Cook and one from Mike Card.
For more details on the discussion, please visit the Forum at ODBMS.ORG.

A copy of the OMG white paper on Next-Generation Object Database Standardization written by the OMG`s Object Database Technology Working Group, can be download here Next-Generation Object Database Standardization

Roberto V. Zicari
--------------

Hi everybody.
I'm sorry that I was not able to attend the meeting on Dec 12. I hope that someone can post some information on it. I think it is great that these topics are being discussed, but I also have some significant disagrements with points being made here.

My biggest issue is that I don't agree with the premise of the OMG RFI and Prof. Subieta's response. The premise is that the problem is "the underlying lack of a set of precise definitions and semantics that has plagued ODMSs for years" [mpcard]. The assumption here is that people didn't use object databases because OODBs didn't have a solid theory like relational algebra. I do not believe that was the reason. I think the reason was that (1) most of the original OODBs systems didn't support query optimization or transactions (2) they had difficulty externalizing their data in a way that could be evolved and used by other tools (3) when the did introduce query languages, they were subject to the same impedence mismatch as relational systems.

I think that Impedence mismatch is a language problem not a data problem. Relational data maps very well to traditional data structures in C, Pascal, or any other programming language: just create an array of records. Relational data maps fairly well to objects too, especially since you can represent relationships easily. The impedence mismatch comes from the need to partition a program into two parts: a query that is sent to the database, and a client program that uses the query results. Previously this partitioning was done by putting the query into a string, which causes all sorts of problems. Native Queries and LINQ are two more modern and effective ways to partition a program into a query and a client, so that the semantic connections between them are preserved. Prof. Subieta's proposal does not address this problem, as far as I can tell.

As for data models, I think that Entity-Relationship models, UML class diagrams, and Subieta's models are all essentially equivalent. They have the concept of records of attributes connected by relationships. The relational model also has ses of records, but the relationships are not explicit in the data model, but must be specified on each join operation. You can argue over fine points of inheritance and such things, but these are small points compared to the basic similarities of the models. It is not fair to compare any of these models to the network model, which as far as I can tell was a hack on top of the hierarchical data model. It is asuming that hierarchical data models have had a resurgence under the name XML; these are very useful for data transmission but are not a suitable foundation for a database.

As for query languages, I don't think that the stack-based query language has anything fundament to offer over OQL. It is like saying that an HP calculator with postfix notation has a more solid theoretical model than a standard calcular that uses infix. I also want to point out that the core of OQL is not really object-oriented, becuase it does not deal with methods. It is just a great query language for ER data models. The key point is "entities and relationships" and that is what OQL was designed for and is good at. I do not agree that OQL is inconsistent. Suad pointed out some difficulties with the Java binding, and perhaps there are some other small problems with the way the standard was defined. But rather than fix these small issues, he claimed that the entire system is inconsistent.
See here for an alternative and more balanced view. I think that Prof. Subieta's query syntax is perfectly reasonable as well. But it is not a fundamental advance, as far as I can tell.

NOTE: Native Queries are not propretary; they were described by one of my students and me in an ECOOP paper and then implemented by db4objects. They have been implemented by others as well, although not in any commercial systems. They are also similar to Microsoft's LINQ in some ways.

So, to summarize. I think that OMQ is again trying to solve the wrong problem. I sent in a response to the RFI; and yes, it wasn't what you wanted to hear. But I'm going to keep saying it.

The problem is not a lack of a grand unifying theory. There is plenty of theory to cover ER models, OQL, and other traditional ideas. The disucssions you are having don't deal with impedence mismatch, which can happen even with an object-oriented language accessing an object-oriented database using OQL! If you put OQL into a string, then you are going to have impedence, and nothing about the formality of the data model or query language is going to fix it. The real problems are impedence mismatch, good query optimization, solid transaction support, evolution of data, and scalability to multiple servers. These are things that OODB vendors didn't address until it was too late. They thought that objects alone would magically make everthing work well. But.. they don't.

I'm sorry to be so negative about this, but I really think that there is an opportunity to improve the DB/PL interface.

Wiliam Cook
Assistant Professor
Department of Computer Sciences
University of Texas at Austin

--------------
Hello Prof. Cook-

You wrote:

"My biggest issue is that I don't agree with the premise of the OMG RFI and Prof. Subieta's response. The premise is that the problem is "the underlying lack of a set of precise definitions and semantics that has plagued ODMSs for years" [mpcard]. The assumption here is that people didn't use object databases because OODBs didn't have a solid theory like relational algebra. I do not believe that was the reason. I think the reason was that (1) most of the original OODBs systems didn't support query optimization or transactions (2) they had difficulty externalizing their data in a way that could be evolved and used by other tools (3) when the did introduce query languages, they were subject to the same impedence mismatch as relational systems."

I don't think the RFI itself had a "premise," at least that I am aware of. Regarding your 3 reasons why ODBMSs were not widely adopted, I would argue that you could trace all 3 of these issues to the lack of a good underlying object model and set of definitions and semantics. I cannot see how you think the "impedance mismatch" or DB/PL interface issue will be solved without laying a good theoretical foundation.

"The problem is not a lack of a grand unifying theory. There is plenty of theory to cover ER models, OQL, and other traditional ideas. The disucssions you are having don't deal with impedence mismatch, which can happen even with an object-oriented language accessing an object-oriented database using OQL! If you put OQL into a string, then you are going to have impedence, and nothing about the formality of the data model or query language is going to fix it."

Sure, but no one has ever tried to tie object definition/store models all the way up to a QL, defined with an abstract query processor, like Prof. Subieta has (at least as far as I have read). It is true that the formality of the data model won't solve the "impedance mismatch" between a query string and a native PL, but again this falls into the area of further work we have to do. Everyone thinks they have the best way to do this: everyone in ODMG thought their APIs were best and their way was best, and that a formal set of definitions, semantics, and object models was unnecessary because in the end developers just need to write code. That's why ODMG chapter 2 was so weak and why there were so many "holes" in the ODMG specification: we were trying to write something that would cover several existing products without requiring anyone to make significant code changes. Users didn't care about the standard because it did not guarantee application code (or even data) portability, so what did it matter? There was no conformance test suite, so you couldn't even say for sure who was conformant to what.

"The real problems are impedence mismatch, good query optimization, solid transaction support, evolution of data, and scalability to multiple servers. These are things that OODB vendors didn't address until it was too late. They thought that objects alone would magically make everthing work well. But.. they don't."

Yes these are real problems but I would argue that solving them will require a common theoretical foundation from which to build. I guess we'll see if there is consensus on that view or not at next month's ODBTWG telecon.

-Mike Card
Syracuse Research Corporation (SRC)

Read the original blog entry...

IoT & Smart Cities Stories
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Atmosera delivers modern cloud services that maximize the advantages of cloud-based infrastructures. Offering private, hybrid, and public cloud solutions, Atmosera works closely with customers to engineer, deploy, and operate cloud architectures with advanced services that deliver strategic business outcomes. Atmosera's expertise simplifies the process of cloud transformation and our 20+ years of experience managing complex IT environments provides our customers with the confidence and trust tha...
Where many organizations get into trouble, however, is that they try to have a broad and deep knowledge in each of these areas. This is a huge blow to an organization's productivity. By automating or outsourcing some of these pieces, such as databases, infrastructure, and networks, your team can instead focus on development, testing, and deployment. Further, organizations that focus their attention on these areas can eventually move to a test-driven development structure that condenses several l...
The graph represents a network of 1,329 Twitter users whose recent tweets contained "#DevOps", or who were replied to or mentioned in those tweets, taken from a data set limited to a maximum of 18,000 tweets. The network was obtained from Twitter on Thursday, 10 January 2019 at 23:50 UTC. The tweets in the network were tweeted over the 7-hour, 6-minute period from Thursday, 10 January 2019 at 16:29 UTC to Thursday, 10 January 2019 at 23:36 UTC. Additional tweets that were mentioned in this...
Over the course of two days, in addition to insightful conversations and presentations delving into the industry's current pressing challenges, there was considerable buzz about digital transformation and how it is enabling global enterprises to accelerate business growth. Blockchain has been a term that people hear but don't quite understand. The most common myths about blockchain include the assumption that it is private, or that there is only one blockchain, and the idea that blockchain is...
Never mind that we might not know what the future holds for cryptocurrencies and how much values will fluctuate or even how the process of mining a coin could cost as much as the value of the coin itself - cryptocurrency mining is a hot industry and shows no signs of slowing down. However, energy consumption to mine cryptocurrency is one of the biggest issues facing this industry. Burning huge amounts of electricity isn't incidental to cryptocurrency, it's basically embedded in the core of "mini...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
The term "digital transformation" (DX) is being used by everyone for just about any company initiative that involves technology, the web, ecommerce, software, or even customer experience. While the term has certainly turned into a buzzword with a lot of hype, the transition to a more connected, digital world is real and comes with real challenges. In his opening keynote, Four Essentials To Become DX Hero Status Now, Jonathan Hoppe, Co-Founder and CTO of Total Uptime Technologies, shared that ...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Every organization is facing their own Digital Transformation as they attempt to stay ahead of the competition, or worse, just keep up. Each new opportunity, whether embracing machine learning, IoT, or a cloud migration, seems to bring new development, deployment, and management models. The results are more diverse and federated computing models than any time in our history.