aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Refactoring Databases : Evolutionary Database Design! Database development speed. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Refactoring Databases : Evolutionary Database Design! Database development speed." Watch "Refactoring Databases : Evolutionary Database Design! Database development speed." New topic
Author

Refactoring Databases : Evolutionary Database Design! Database development speed.

Branko Santo
Ranch Hand

Joined: Oct 15, 2005
Posts: 72
Hello,

First think to notice is that this is available in a hard cover which is pretty much suprising considering the speed of development of tech books these days. I guess it is built to last a while with such a long lasting topic.

Now for the question.

Looking at the computer power and such quick operating systems it has become obvious that humans are becoming more of a problem than of a solution. Programmers who because of their lack of persistance and discipline make such errors wich produce critical bottlenecks can destroy a complete business model of an application be it online or a desktop one.
As database is a hot topic these few years it is imperative that high priority be given to it, it is not only a data repository but an integral part of any application that uses it and programmers who take it lightly thinking just beefing up their machines is going to help are in for a world of trouble.
So what is your tought are database design topics going to overtake the chase for faster DB's and searching algorithms. It is clear that for 99.99% of apps and sites todays DB's are more than sufficient, but many strugle with keepeing them afloat.

Thank you
Branko Santo
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Branko Santo:
... available in a hard cover which is pretty much suprising considering the speed of development of tech books these days.


Actually the area for Data Professionals tends to move a bit slower than other more "fashionable" areas of IT. Unfortunately this also means that they may also be a bit slower in adopting new effective software development processes and practices.
Many of Scott Ambler's books aim to change that, including:
Refactoring Databases: Evolutionary Database Design
Agile Database Techniques: Effective Strategies for the Agile Software Developer
Rita Williams
Greenhorn

Joined: Jan 30, 2001
Posts: 10
As a college instructor, I seldom use a textbook for more than 2 years. Trying to keep a technology textbook current in the market is an ongoing task with no end in sight for the author.


In "The Skillset of an Agile DBA" at http://www.agiledata.org/essays/dbaSkills.html, Scott recommends that a DBA
"should be prepared to data model using the UML". Here is another perspective based on how we are training the next generation of professionals.


I use Mannino's "Database Design, Application Development & Administration" as a text, but it only has 4 pages, out of 700, that discuss UML for database design. This is a very small beginning to bridge the gap between development and database professionals in their training.


This fall, I will teach a course in Information Systems to Accounting students. The Gelinas "Accounting Information Systems" text has 3 paragraphs on object-oriented database models, but I didn't find UML mentioned at all. The text introduces context diagrams and data flow diagrams to document system design. It seems to me that accountants will consume information from the database and audit the reports of the database applications, but will have to build their own bridges with their IT colleagues.


Maybe we need an Agile Accounting movement!

Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
In "The Skillset of an Agile DBA" at http://www.agiledata.org/essays/dbaSkills.html, Scott recommends that a DBA
"should be prepared to data model using the UML". Here is another perspective based on how we are training the next generation of professionals.


Yes, and I'm happy to say that the OMG has an RFP for information modeling right now.

I use Mannino's "Database Design, Application Development & Administration" as a text, but it only has 4 pages, out of 700, that discuss UML for database design. This is a very small beginning to bridge the gap between development and database professionals in their training.


Perhaps this is an indication that the vast majority of the data community are a little too bit narrowly focused on their aspect of IT? In the November issue of Dr. Dobb's Journal (www.ddj.com) I'm going to summarize a survey which explored the current state of data management within IT organizations today. I can't reveal the results yet, but the short story is that the data community has a lot to answer for.

This fall, I will teach a course in Information Systems to Accounting students. The Gelinas "Accounting Information Systems" text has 3 paragraphs on object-oriented database models, but I didn't find UML mentioned at all.


OODBs are an interesting niche technology, but I'm not so sure that many accounting systems are based on them.

The text introduces context diagrams and data flow diagrams to document system design.



Those are great techniques, which I cover at www.agilemodeling.com BTW, but rather outdated. My advice: use the right artifact for the situation.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Kevin Mangold
Greenhorn

Joined: Jan 13, 2005
Posts: 18
I beleive that design topics will never go out of scope, no matter how much technology evolves. I have many old design books as well as many new ones, including database design. The content of the new and old books are generally the same. How can you change the way you design something abstract?

As far as database design goes, UML, I beleive, is very key in creating a well structured database schema. You'd think that a common sense design would be apparent to most (if not all) programmers, database administrators, IT professionals, etc. I have worked for the government for a four years now and I have yet to see a decently designed schema. Even designs thought to be appropriate twenty years ago would have received my approval. There was no planning involved.

Even if UML isn't explicitly used, any form of planning, outlining or drawing the structure of a schema will in some way use UML. Application/database design has been around since the beginning. The term UML hasn't come into play really until the past 10-15 years.

To answer your question Branko, design will never disappear, nor will the search for faster or more efficient ways of searching. It's best to be kept separate. A database administrator should not have to worry about speed of efficiency. They need to worry about design since that will be their responsibility. Speed and efficiency should be left for the database programmers/engineers.
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Kevin Mangold:
As far as database design goes, UML, I beleive, is very key in creating a well structured database schema.


Interestingly Microsoft has been pushing Terry Halpin's Object Role Model (ORM) with its conceptual schema for this purpose - I suspect because it deliberately delays the identification of the "containing structures"; it focuses on types of known facts, the constraints on them, and rules for deriving facts. It also outlines a step-by-step process: the Conceptual Schema Design Procedure (CSDP):
  • Transform familiar examples into elementary facts and apply quality checks.
  • Draw the fact types and apply the population check
  • Check for entity types that should be combined, and note any arithmetic derivations.
  • Add uniqueness constraints, and check the arity of fact types of fact types.
  • Add mandatory role constraints, and check for logical derivations
  • Add Value, set comparison, and sub-typing constraints
  • Add constraints and perform final checks


  • Halpin also provides algorithms for converting a conceptual schema to ERD or UML.

    Terry Halpin: Information Modeling and Relational Databases: From Conceptual Analysis to Logical Design (ISBN: 1558606726)
    Morgan Kaufmann/Elsevier US
    Companion site
    amazon US

    MSDN: Object Role Modeling: An Overview
    Agile Modeling: Object Role Model (ORM) Diagrams

    I've run across some accounts where people liked the "sentences" from the initial phases of the CSDP but weren't so fond of the graphical aspect of ORM, mainly due to the puzzled looks on the faces of the domain experts.
    Rita Williams
    Greenhorn

    Joined: Jan 30, 2001
    Posts: 10
    I just ran across an article at Oracle


    http://www.oracle.com/technology/oramag/oracle/06-jan/o16xml.html


    "Know Your UML with XML: Learn how Oracle XML DB can increase ROI on UML models of software systems"


    The authors describe a process which starts with a UML model, extracts to XML, then uploads to Oracle XML DB (based on Oracle 10g)-- thus making it possible to use SQL.

    Do you think this is hype for Oracle or would it be really useful for large systems?
    Scott Ambler
    author
    Ranch Hand

    Joined: Dec 12, 2003
    Posts: 608
    The real issues are:
    1. To think through what you're doing (e.g. do some design) before you build it. If visual modeling works for you, discussion, or writing tests first then that's perfectly fine.
    2. If you're going to model visually, then you need to use a modeling language which everyone involved understands. ORM is a great notation, but few people understand it. There are several other data modeling notations but the data community never standardized (why does it seem that they like to force standards on others but not on themselves? hmmmm.... ;-) With UML, at least the development community is in the process of learning it and frankly if you know one of the common data modeling notations then using UML is a no brainer. As I show in UML data modeling UML is arguably more complete for physical data modeling than the other common data modeling notations.

    - Scott
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Refactoring Databases : Evolutionary Database Design! Database development speed.