Browsing articles tagged with " data modeling"

The Key to Keys at the North Texas SQL Server User Group – 17 March

Mar 15, 2016   //   by Karen Lopez   //   Blog, Data Modeling, Database, Database Design, DLBlog, Speaking, SQL Server  //  No Comments

I’m visiting Dallas this week to speak at the North Texas SQL Server User Group this Thursday.  I’ll be speaking about keys: primary keys, surrogate keys, clustered keys, GUIDs, SEQUENCEs, alternate keys…well, there’s a lot to cover about such a simple topic.  The reason I put this presentation together is I see a lot of confusion about these topics. Some of it’s about terminology (“I can’t find anything about alternate keys in SQL Server…what the heck is that, anyway”), some of it is misunderstandings (“what do you mean IDENTITIES aren’t unique! of course they are…they are primary keys!”), some of it is just new (“Why the heck would anyone want to use a SEQUENCE?”).

We’ll be chatting about all these questions and more on Thursday, 17 March at the Microsoft venue in Irving, Texas starting at 6PM.

Attendance is free, but you need to register at http://northtexas.sqlpass.org/ to help organizers plan for the event.

Don’t worry if you don’t know about SQL Server or don’t use it: this presentation will focus on some SQL Server specific features, but the discussion is completely portable to other DBMSs.

So many of us have learned database design approaches from working with one database or data technology. We may have used only one data modeling or development tool. That means our vocabularies around identifiers and keys tend to be product specific. Do you know the difference between a unique index and a unique key? What about the difference between RI, FK and AK? These concepts span data activities and it’s important that your team understand each other and where they, their tools and approaches need to support these features. We’ll look at the generic and proprietary terms for these concepts, as well as where they fit in the database design process. We’ll also look at implementation options in SQL Server and other DBMSs.

Hope to see you there!

Follow Up to State of the Union of Data Modeling 2016–Questions for You

Feb 1, 2016   //   by Karen Lopez   //   Blog, Data Modeling, DLBlog, Speaking  //  2 Comments

DATA spelled out in cereal letters

I had so many more questions I wanted to talk about during my recent State of the Union of Data Modeling 2016, but one hour goes by quickly when you have tools, industry, professionals, standards and user groups to cover.  I’m interested in your observations and comments about these questions:

  • Has data modeling accomplished all it needs to? Are we just in the maintenance phase of data modeling as a practice and profession?
  • What industry trends (tools, processes, methods, economics, whatever) are impacting (positive or negative) data modeling the most today?
  • How has the cost of data modeling changed since 1980s?
  • How has the return on data modeling changed since the 1980s?
  • How has risk changed in data modeling since the 1980s?
  • Data Modeling tools have so much maturity of features in them today.  But along with that prices have reflected those changes.  How have the prices of enterprise data modeling tools impacted data modeling on enterprise projects?
  • Have you worked with any non-IDEF1x/IE data modeling notation recently?
  • Have you worked with any open source data modeling tools?
  • What new features/enhancements/changes would you like to see in data modeling tools? Processes? Notations?
  • Why haven’t we solved the “no one loves me or my models” problem more widely?

I’ll add my thoughts on these in the comments, but I’d like to hear your responses as well.

You’re Doing it Wrong: Generalizations about Generalizations

What Could Go Wrong Complicated Data Model Thumbnail Plus Darth Vader

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 generalized 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.

Sometimes data architects apply these patterns but don’t bother to apply the governance of those rules to the resulting systems

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 (affiliate link).  Generalization isn’t just a yes/no position.  Every data model structure you architect has a level of generalization.

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.

Update: I updated the link to Alec’s blog post.  Do head over there to read his points on generalization.

Make Your Data Work for You

Jul 12, 2014   //   by Karen Lopez   //   Blog, Data, Fun, Snark  //  No Comments

image

Big Data, NoSQL and Data Modeling: Big Challenges in Data Modeling

Jun 24, 2014   //   by Karen Lopez   //   Blog, Data, Data Modeling, Database, Database Design, Events, NoSQL, Speaking  //  1 Comment

Database table

Big data and NoSQL have led to big changes In the data environment, but are they all in the best interest of data? Are they technologies that "free us from the harsh limitations of relational databases?" as I recently blogged about at Dataversity.net?

In this month’s webinar (register now), we will be answering questions like these, plus:

  • Have we managed to free organizations from having to do data modeling?
  • Is there a need for a data modeler on NoSQL projects?
  • If we build data models, which types will work?
  • If we build data models, how will they be used?
  • If we build data models, when will they be used?
  • Who will use data models?
  • Where does data quality happen?
  • Are there NoSQL technologies for which data modeling will never apply?

Finally, we will wrap with 10 tips for data modelers in organizations incorporating NoSQL in their modern data architectures.

Join NoSQL expert extraordinaire Dan McCreary ( blog ) and others (including YOU!) as we talk about the future of data modeling and data modelers this Thursday, 26 June, at 2PM EDT.

We’ll also have some prizes to give a way, so plan on attending live.

 

(BTW, don’t get me started on the lame modeling styles/naming standards in stock photography.  Maybe I should start making some for Getty Images?)

This Thursday, Big Challenges in Data Modeling: The Need for Speed #BCDModeling

May 20, 2014   //   by Karen Lopez   //   Blog, Data, Data Modeling, Events, Project Management, Speaking  //  1 Comment

 

clip_image001

22 May 2014, 2PM EDT
Register: http://www.dataversity.net/may-22-webinar-big-challenges-data-modeling/ 

It’s May, which sets this former Hoosier thinking of racetracks and Indy cars. I’m also a runner and that means I’m always thinking about pace and timings…and feeling guilty about not training hard enough.

This got me musing about how data modelers can speed up the data modeling process — not just during a development projects, but at all points in our work day. So let’s have a discussion about

In this month’s webinar, we’ll talk about:

  • The Need for Speed
  • Sprints, marathons and training
  • Race cars, horses, carts, and feet
  • Qualifiers and Races
  • Pace cars
  • Backseat drivers
  • Rules, tickets and enforcement
  • Fads, gadgets and automation
  • Red, yellow, green and checkered flags
  • How do you know when to stop racing?

 

Joining me in the discussion will be two wonderful panellists:

Donna Burbank

Donna Burbank, VP, Information Management Services at Enterprise Architects ( @donnaburbank )

Carol Lehn

Carol Lehn, MDM Database Designer at PepsiCo ( @lehnca )

And as usual, our attendees will have the opportunity to participate via chat and Q&A as our final panellist.

Register: http://www.dataversity.net/may-22-webinar-big-challenges-data-modeling/

Pages:123456»

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


Categories

Archive

UA-52726617-1