Google Web

mewsings, a blog


Sunday, January 15, 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 would want even if you did have a relational database backing an ordered property list. And 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?

See comments.


At 4:25 PM , Anonymous said...

It makes sense to me, even though I am not yet buying into the non-relational model. I do understand what you are saying.



Post a Comment

<< Home

Litter Box

Musings about software development, with a focus on data modeling.

Atom feed

Some of this is worth pawing through.