Browsing articles tagged with " ARTS Data Model"

I’m Speaking: DAMA PDX – 24 Feb – Industry Standard Data Models + Career Success

Feb 24, 2011   //   by Karen Lopez   //    //  1 Comment
Don Valley Golf Course

Image by Karen Lopez via Flickr

I’m going to be doing TWO presentations at DAMA Portland (OR) on Thursday, 24 February.  I so very much love visiting Portland and the members of this DAMA group are great for engaging and inspiring conversations during the presentations.

The topics I’m covering:


Career Success in Data Management during Turbulent Times

A workshop on issues and ideas that today’s data architects and modelers can do to build their careers and networking skills with other data management professionals.

Workshop topics will include:
• Demonstrating your expertise
• Building a portfolio of your success stories
• Getting others to sell your skills and business value
• Building & extending your data management skill set
• 10 Steps to highlighting you and your work

Bring your thoughts, ideas, and experiences.


This presentation talks about how to get others to help sell your skills, how networking (talking to people, not passing out business cards) can help you advance your project and your skills, and how to having a portfolio of great career data can help you demonstrate your professional abilities.


Starting with More than a Blank Page: Modeling with an Industry Standard Data Model

Have you ever considered using pre-existing pattern models to jump start your data modeling projects?  Have you considered purchasing proprietary models? Did you know that there are hundreds of models available to you for free or for minimal cost?

Many industry trade associations publish industry standard data models (ISDMs).  These models focus on the core and supporting business functions associated with retailing, health care, criminal justice and other industry sectors.  They may be provided free to the public or for just the cost of joining a trade association.

In this presentation, Karen discusses some of the benefits and gotchas of working with acquired models – industry standard models, patterns, and other universal model concepts.   This session includes topics such as:

  • The costs, benefits, and risks of working with industry standard data models
  • The benefits of using industry standards in your package acquisition projects
  • Choosing the right process
  • Myths in working with pattern models
  • 10 Tips for successfully working with third party models
  • What you should know before committing to project plans and estimates
  • Lessons Learned
  • Resources

Find out what other organizations are doing with industry standard data models — how vendors and industry organizations are partnering to set standards that your organization will want to leverage for better meet the business needs of your solutions.


I’ve added some more live examples of industry standard data models (ARTS and NIEM) to this presentation to help demonstrate typical data models that are prepared for industry-specific examples.

I hope you can join me in Portland.

Cost

Free for members!
$15 for non-members.
See the list of corporate members.

RSVP

at DAMA-PDX website by noon Friday, February 22, 2011

You’re Doing it Wrong: Generalizations about Generalizations

Nov 17, 2010   //   by Karen Lopez   //   Blog, Data, Data Modeling  //  3 Comments

I have a couple of presentations where I describe how generalized data modeling can offer both benefits and unacceptable costs.  In my Data Modeling Contentious Issues presentation, the one where we vote via sticky notes, we debate the trade-offs of generalization in a data model and database design.  In 5 Classic Data Modeling Mistakes, I talk about over-generalization.

Over the last 20 some years (and there’s more “some” there than ever before), I’ve noticed a trend towards more generalizalized data models.  The means that instead of having a box for almost every noun in our business, we have concepts that have categories.  Drawing examples from the ARTS Data Model, instead of having entities for:

  • Purchase Order
  • Shipping Notice
  • Receipt
  • Invoice
  • etc

…we have one entity for InventoryControlDocument that has a DocumentType instance of Purchase order, Shipping Notice, Receipt, Invoice, etc.

See what we did there?  We took metadata that was on the diagram as separate boxes and turned them into rows in a table in the database.  This is brilliant, in some form, because it means when the business comes up with a new type of document we don’t have to create a new entity and a new table to represent that new concept.  We just add a row to the DocumentType table and we’re done.  Well, not exactly…we probably still have to update code to process that new type…and maybe add a new user interface for that…and determine what attributes of InventoryControlDocument apply to that document type so that the code can enforce the business rules.

Ah! See what we did there this time?  We moved responsibility for managing data integrity from the data architect to the coders.  Sometimes that’s great and sometimes, well, it just doesn’t happen.

So my primary reason to raise generalization as an issue is that sometimes data architects apply these patterns but don’t bother to apply the governance of those rules to the resulting systems.  Just because you engineered a requirement from a table to a row does not mean it is no longer your responsibility.  I’ve even seen architects become so enamoured with moving the work from their plate to another’s that they have generalized the heck out of everything while leaving the data quality responsibility up to someone else.  That someone else typically is not measured or compensated for data integrity, either.

Alec Sharp has written a few blog posts on Generalizations. These posts have some great examples of his 5 Ways to Go Wrong with Generalisation.   I especially like his use of the term literalism since I never seem to get the word specificity out when I’m speaking. I recommend you check out his 5 reasons, since I agree with all of them.

1 – Failure to generalize, a.k.a. literalism

2 – Generalizing too much

3 – Generalizing too soon

4 – Confusing subtypes with roles, states, or other multi-valued characteristics

5 – Applying subtyping to the wrong entity.

By the way, Len Silverston and Paul Agnew talk about levels of generalization in their The Data Model Resource Book, Vol 3: Universal Patterns for Data Modeling book.  Generalization isn’t just a yes/no question.  Every data model structure you architect has a level of generalization.

I’m wondering how many of you who have used a higher level of generalization and what you’ve done to ensure that the metadata you transformed into data still has integrity?  Leave your recommendations in the comments.

Subscribe via E-mail

Use the link below to receive posts via e-mail. Unsubscribe at any time. Subscribe to www.datamodel.com by Email


Recent Comments

Categories

Archive

UA-52726617-1