mewsings, a blog

--dawn

← Previous   Next →

Monday, January 16, 2006

Who Ordered the Ripple Delete?

Ripple Delete with Digital Video Editing

I have dabbled a bit in digital video editing, inserting and deleting frames, for example. If I select frames and hit the keyboard Delete, the frames are removed, but a gap remains where they once were. That is often not what I want. Enter: the ripple delete. I'll admit to having a slight shiver of delight when I perform a ripple delete. Behind the scenes it not only deletes the frames, but moves frames up to cover the gap. Editors who have worked with physical film and a razor blade must be ecstatic.

The frames of a video are similar to any other ordered list of data. This ripple delete feature can be added to any software application that shows users an ordered list. Product features are not determined by a particular underlying database data model. However, I am using the feature of an ordered list to set the stage for investigating the meaning and implications of chosing one or another data model, with a definition for "data model" coming in the next blog. If the same features can be implemented in software whether using the Relational Model (RM) or not, why might a team choose not to employ the RM?

Rather than avoiding ordered lists, you start seeing how common they are when you free your mind of the RM.

Let's turn to an example of a simple ordered list. If I were not such a novice with AJAX, I might have provided an example of a ripple delete on a list, but my working example should help with the illustration none-the-less. Also, please forgive my burst of saccharin marketing spin, but because of using

  • tag-delimited strings
  • NF2 and
  • two-valued logic (2VL)

throughout the entire development process, I'm naming this style of development End-to-End AJAX or maybe N2N AJAX. You can gag now, but it isn't like naming JavaScript after Java, given that AJAX really is used at the front-end.

Using the example from the last blog, I'll add a requirement for the e-mail addresses to be ordered. Someone using the database would send either bulk or individual e-mails first to the first address and if that bounces, then to the second. I can place an ordered list in my logical model and then in my implementation. That way I can enjoy use of the ordered list without managing a separate ordering attribute myself, without having to remember to sort the output, nor writing my own ripple delete process.

See this example as a hint at developing using End-to-end AJAX. While a ripple delete is not a standard feature of an RDBMS, it is part of the charm of MV databases. So, the e-mail list is defined as an ordered list to our database. AJAX is used on the front-end, including xhtml, css, and JavaScript. The output comes from a query of the database without procedures to reshape it, so you can see that the database includes NF2 data, as described in the first blog.

In practice, data modelers are influenced in their choices of a logical data model by their target DBMS. If the target database is based on the RM, the data modeler is less likely to select a property list for an entity (i.e. a multi-valued attribute requiring a new table in a SQL-DBMS). I have heard analysts convince users that a single-valued attribute would be best or at least appropriate "for this phase." It makes sense that if you have to split an attribute into a separate table, add in an ordering attribute and roll your own insert and ripple delete functions, you are simply less likely to even consider it. A technique sometimes used when lists are implemented in an RDBMS is to number using intervals that permit easy insertion in the midst of the list as long as you do not run out of numbers in the interval. There is then no hint in any given entry in the list what its ordinal position might be. If the first e-mail address were identified as address 10 and the second were numbered 20, another e-mail address could be inserted as 15. But, rather than avoiding ordered lists, you start seeing how common they are when you free your mind of the RM.

Even once you go through the work of implementing an ordered property list for an entity, the end-user might still be affected if you take your RM thinking to the UI. Think what the digital video editing tool user interface might be if it were to think like the RM. It is unlikely that this editing software holds these frames in a relational database but it shows the interface your users might want even if you did have a relational database backing an ordered property list. Now don't forget, software developers are users too. The DBMS APIs they use can make a significant difference.

Some...might think I'm about to confuse the data model with a representation.

Some readers around the world (I was thrilled to have readers from every continent except Antartica this past week with the first blog) might think I'm about to confuse the data model and the representation. I'm not. I am laying the groundwork for examining the definition and use of a data model. What is the relationship between a data model and the API that developers use in working with a DBMS? If we can have ordered lists and perform ripple deletes no matter what data model we are using, then what is my point? It has to do with the title of this blog—between the developer and the database, who did what work; who ordered a list of properties? For flexibility or productivity, does it make a difference who ordered the ripple delete?

← Previous   Next →

11 Comments:

At 6:26 AM, January 17, 2006 , Anonymous rossferris said...

Dawn,

I don't mean to be too harsh, but ...

I'm confused. I don't understand WHY we have the example of an AJAX style application in the middle of a discussion of ordered lists with ripple delete? OK, you qualify this by "The output comes from a query of the database without procedures to reshape it, so you can see that the database includes NF2 data",

But HOW do I know that the data includes NF2 data? The email addresses could just as easily be originating from a 32/64K "free text" chunk out of "any" database.

Also, I know that your current target audience are the mv "faithful", but your backend code possibly should have handled the entry of "123" a little better, and the front end could have responded to TAB OR ENTER with minimal change. Also, if the purpose of the mewsings is to promote the "ease" & "benefits" of mv technology, then perhaps a little less HTML, CSS, Java Script & PHP might in order I would suggest that perhaps demonstrating the "base query" buried in the php code may have been more illustrative

 
At 9:10 AM, January 17, 2006 , Blogger --dawn said...

Hi Ross -- While I didn't intend to confuse the "MV faithful" (you prefer that to "old Pickies"? ;-) my desired audience for the blog is the software development community at large. I'm particularly interested in talking with those interested in web-based development, likely currently using SQL-based databases. The purpose of mewsings is to promote big-bang-for-the-buck approaches to software development with an initial focus on data modeling, promoting a move beyond the RM for end-to-end development using NF2 and 2VL. I am using MV as an example of one such alternative. There are others, but I have some familiarity with MV.

I'm very interested in AJAX and web development standards for the front-end with non-SQL solutions on the backend. I have a learning curve with AJAX and OpenQM, but hope to develop examples of End-to-end AJAX development throughout the coming year.

To answer your question about HOW you know, the source code is there for this one little example (however flawed--I'll look into your comments on that). Interested readers can see the MV query, but what that query looks like was not the point of this blog. Query languages will certainly be addressed at some point, however.

Thanks for reading and getting the comments started on this one. --dawn

P.S. By the way, for readers who are interested in their options for software development along these lines, you will get further faster by using Ross's Viságe product from www.stamina.com.au rather than building from scratch as in my little example (and I'm not just saying that to suck up to Ross).

 
At 9:15 PM, January 17, 2006 , Anonymous Mike Preece said...

Just a note to add that, while Visage is an option, there are many others. Perhaps the readers might like some background on the various presentations made at the Spectrum conferences and/or the "bake-off".

Mike.

 
At 11:16 AM, January 20, 2006 , Blogger --dawn said...

Good point, Mike. Yes, there are many products in the MultiValue space. I'm not trying to pitch any such, however, so I have not plans to include such information in this blog. Someone also requested links to the various MV databases mentioned in the first blog. I could add some links on my web site for such, although any company wanting to advertise on the site can already do so. It is not my intent to push Pick, but rather to use logic and examples to show there are viable, even better, alternatives to the relational model. Feel free to include any URLs you would like in the comments. Cheers! --dawn

 
At 3:01 PM, January 21, 2006 , Anonymous Anonymous said...

I must admit the AJAX example doesn't click at all. Are you talking about interface techniques, logical models, or theoretical data models? What does AJAX have to do with it?? Actually, to me AJAX is yet another example of how the IT industry rarely moves forward and simply comes up with new names for old things...

If this is an argument for not using the RM, I don't get it. The RM is a general model, and as I believe I mentioned in a previous comment, using a type system with multi-valued attributes would allow you to model an MV system with the RM, ripple delete or not. Put your data in relations with multi-valued attributes, or use relations with scalar attributes and design a layer that exposes the same logical model as the multi-value system. Once this model is created, implement it however is easiest. As usual, SQL makes it difficult, but again as usual, that's not the RM's fault.

In order to abandon the RM as an abstract model or a "way of thinking", I would have to find another model that is 1) at least as general 2) can handle something that the RM can't. Since the RM allows for completely arbitrary attributes, which are assigned meaning via arbitrary predicates, and which are constrained by arbitrary assertions, I'm not sure what else you'd need!

I would find these posts easier to swallow if they just didn't mention the RM at all, and moving "beyond" the RM, and so on....nothing you're saying is really an issue with the RM as a theoretical model!

 
At 3:04 PM, January 21, 2006 , Anonymous Anonymous said...

PS: History_of_Pick.mpg?

 
At 3:20 PM, January 21, 2006 , Blogger --dawn said...

Hi Anonymous -- I'm writing the next blog on the meaning of "data model" so hopefully that will resonate a bit more. For this current one, I laid out an example of doing end-to-end development using exclusively Non-First Normal Form and two-valued logic, no RM-thinking necessary at all, to show you can do that and give a hint at what the data model might look/think like.

I do realize I haven't presented a complete argument against use of the RM at this point. I'm certain I won't change minds about the RM in just a couple of blogs, but hope you will hang in there and keep letting me know what isn't working for you. Thanks. --dawn

 
At 8:29 PM, January 23, 2006 , Blogger Gabriel Florit said...

Hi Dawn,

Steps that brought me here:

1) Last week I was told I've to write an AJAX framework for our program, since I'm the one with the most knowledge (which means no one here knows a thing about it...).

2) I go on to read Zeldman's Web 3.0 article on ALA, and become both confused and excited at his soon-to-become-infamous line, "wireframing AJAX is a bitch"? I say, people of the world, what???!!!!

3) I'm reminded of the work we attempted last summer, and come here. Am pleasantly surprised you're blogging! Even more surprised to see you mix databases and AJAX. That was sneaky.

4) Pretty cool demo AJAX demo. And no, I don't think it's a fad. Just an entirely new design paradigm.

 
At 12:20 PM, February 01, 2006 , Anonymous Anonymous said...

>4) Pretty cool demo AJAX demo. And no, I don't think it's a fad. Just an entirely new design paradigm.

It's a long-term fad(like most other renamed web technologies) and it's not a new design paradigm. It's just a (large) pre-wrapped set of existing technologies to help people who don't want to actually learn the underlying technologies.

DHTML/CSS/JS has been around for several years. XML has been around for several years. People have been mixing the two technologies, for just as long, to achieve what AJAX is "doing new".

You can bundle crap in a gold-lined silver box with a platinum bow, but when you open it up it's still just crap. :P When the browser isn't a "browser" anymore and the web sever isn't just a "web server", things will actually change. The W3C is definitively driving all of that, with Microsoft completely skewing the best path for implementations. There's a huge variety of connected browser technologies being brewed, based on the existing stale architecture of the HTTP 1.0 and 1.1 standards. AJAX just happens to be a small player that people in the Pick community find easier to learn than say Ruby-on-rails. That's not a suggestion, just an example alternative.

That's my .0001 cents.

Glen

 
At 1:39 PM, February 01, 2006 , Blogger --dawn said...

Hi Glen -- I agree that AJAX is just a marketing term, but it is showing up what technologies are helping make rich user interfaces through web browsers a reality. This packaging of a term for the tools related to the use of the XMLHttpRequest object in ECMAScript (JavaScript) was done because of the successes in working with such tools.

Ruby (including on Rails) doesn't provide the rich user interface unless coupled with JavaScript. JavaScript actually working in a cross-browser way and providing a rich UI environment does represent a turning point for JavaScript and also for web applications. AJAX helped launch JavaScript from the periphery of software development to the mainstream and helped move the browser into the heart of software development, not just "web page" development.

I don't actually see anything about AJAX that would be more attractive to Pickies than to others, but I see things about Pick that might be attractive to AJAX developers in not having to deal with an OO-RM mismatch.

I would say that with the AJAX strategy (which could include pretty much anything on the back end), the browser isn't the same browser as it has been. You can have highly interactive applications like Google maps, for example. I have been avoiding using the browser as a UI for "real software applications" but I am now jumping into the mix and am much more interested in what I call "web dev."

Cheers! --dawn

 
At 2:45 PM, February 01, 2006 , Anonymous Anonymous said...

Dawn,

Since this is WOT, I'll just state that Flash has been able to do what AJAX is trying to do, for a _long_ time. Unfortunately, only graphical designers have been marketed to - until recently (Flash MX and v8.0). There is a simple scripting language(similar to VB called ActionScript) in Flash. Newer releases of Flash have been redesigned to be a better fit for web developers in the programming world instead of grafx gurus that can write a little VBscript and JS. Flash can do a LOT more than AJAX, with fewer requirements from the browser and client computer. If you enjoy working with AJAX, then I applaud the patience and project skills which allow you to work with it. :)

http://www.actionscript.org/
Be sure to stop by and look at the tutorials for a quick code review.

Glen

 

Post a Comment

<< Home