By Karen Lopez on Sunday, June 25, 2006 11:35 AM

An article over on techworld.com reports that Microsoft will offer data modeling support in Visual Studio called Microsoft Entities :

The ADO team's ADO.Net Entities moves the data model up from the physical structure of relational tables to a "data model that more accurately represents business entities such as 'Customer' or 'Order' that could map to multiple relational tables and views," said S. "Soma" Somasegar, corporate vice president of the developer division at Microsoft. His blog is frequently a source of insight into what is going on at Microsoft.

A preview of Entities is due before the end of this year, and it will be in the Orcas version of Visual Studio.

Entities will allow developers to define complex mapping to relational data, enabling development of new business structures when the data schema cannot be changed, Somasegar said.

To me, though, this sounds more like functionality that DBMS vendors put on top of their engines in the mid-Eighties to make them look and feel more relational. 

What's really going to frustrate me when this comes out is all the conversations that go like this:

Me:  So if you look at the CUSTOMER entity, you c.....

Bob:  Uh, that's not an entity.

Me:  Are you saying that you believe it should be split? Or combined with another entity?

Bob:  I'm saying that you don't know what you are talking about, that's not an ADO .Net Entity..

Me:  Yes, this is a data model, not a ....

Bob:  Nope, that's not what a data model is.

Me:  Uh...not again.

I guess though, that since they chose not to call it ADO .Net Classes, at least they are admitting that classes and entities are not the same thing.  And perhaps that by wanting to appear to be more business-oriented, they believe that there is some value in business modeling and understanding business rules. Maybe.

By Karen Lopez on Friday, June 16, 2006 10:10 PM

Like all good web-mistresses, I check our logs on a regular basis to see which search terms are used to get to our sites.  I do get some terms that I expect, such as modeling tools, data model, data modeling, etc.  But one of the top 5 search terms on a regular basis is MMOPN32.exe or MMOPN.

Those of you that use ERwin will recognize this as the executable for ERwin Data Modeler, at least it is for earlier versions.

I wonder if the reason that this is such a common term is that people are seeing this in an error message or a Zone Alarm warning and they want to know what it is.

If you reached our site by searching for MMOPN32.exe, could you let me know why you are searching on this term.  For the most part, I'm just curious.

Oh, and from what I can remember, if you are getting an error, try renaming c:\winnt\erwin40.ini  and restarting.  You may want to reboot.  And get upgraded to a new version :).

 

By Karen Lopez on Friday, June 09, 2006 3:07 PM

What do the following sentences have in common?

Long mad detail.  Late, mild gonad.  Gloat idled man. Aligned, mad lot.  Managed IT doll.   Get dial old man.  Get laid old man. God! tall maiden. Leading, mad lot.

... read about them in our article Semantics, Schemantics.

By Karen Lopez on Wednesday, June 07, 2006 11:48 PM

I've added a quick data management crossword to our Fun Page.  If you have words and clues to supply, let me know.   This crossword uses java, so you may have to allow for active script on the page in order to play.

Send your words and clues to website@infoadvisors.com.

 

By Karen Lopez on Monday, June 05, 2006 4:38 PM

From our Book Study of Chris Date's Database in Depth:

I thought that this was a good point in Chapter 1, about why we need to study the foundation upon which our profession is based:

The point about principles is this: they endure. By contrast, products and technologies (and the SQL language, come to that) change all the time—but principles don’t. For example, suppose you know Oracle; in fact, suppose you’re an expert on Oracle. But if Oracle is all you know, then your knowledge is not necessarily transferable to, say, a DB2 or SQL Server environment (it might even get in the way of your making progress in that new environment). But if you know the underlying principles—in other words, if you know the relational model—then you have knowledge and skills that will be transferable: knowledge and skills that you’ll be able to apply in every environment and that will never be obsolete.

So we've all probably studied a bit about normalization, perhaps some about surrogate keys, primary keys, and the specific syntax of our DBMS's implementation of SQL, but have we studied those tool and vendor independent topics that allow our skills to be transferable?

I thought that I had a clear distinction in my mind until I sat down one day to work in Oracle.  I needed to get some sample data out of an Oracle database and I normally do this by building a query, then limiting it to the TOP 100 rows.  Guess what?  TOP 100 works just fine in SQL Server, but Oracle doesn't have a clue what to do with that syntax.  It seemed so straight forward to me...

Date goes on to say:

Although it’s certainly possible to use SQL relationally (for the most part, at any rate), sometimes you’ll find—because existing implementations are so far from perfect—that there are severe performance penalties for doing so...in which case you might more or less be forced into doing something not "truly relational" (like writing a query in some weird and unnatural way in order to get the implementation to use an index). However, I believe very firmly that you should always make such compromises and trade-offs from a position of conceptual strength. That is:

• You should understand what you’re doing when you do have to make such a compromise.

• You should know what the theoretically correct situation is, and you should have very good reasons for departing from it.

• You should document those reasons, too, so that if they go away at some future time (for example, because a new release of the product you’re using does a better job in some respect), then it might be possible to back off from the original compromise.

The following quote—which is attributed to Leonardo da Vinci (1452–1519) and is thus some 500 years old!—sums up the situation admirably:

Those who are enamored of practice without theory are like a pilot who goes into a ship without rudder or compass and never has any certainty where he is going. Practice should always be based on a sound knowledge of theory.

(OK, I [Date] added the italics.)

I think that is a brilliant quote, and this position (Practice should always be based on a sound knowledge of theory.) forms the beginning of every professional career, except for IT. 

Where are your foundations?  In a three ring binder that you threw out to make way for the newest set of language references for you DBMS?  In a help file?  Still looking for them?

By Karen Lopez on Friday, June 02, 2006 4:16 PM

As many of you know, one of my practice areas is tailoring IT development methodologies to address privacy and other compliance-related requirements.  If you have attended one of my presentations, you'd know that I advocate the start of privacy and compliance issues at the beginning of the project -- at Project Charter time.

One organization here in Canada, MBNA, appears to have missed out on the cluetrain when it comes to protecting their customers and the public.  Every month or so, I get a new offer of credit: credit cards, lines of credit, loans, you name it, they offer it.  And offer it, and offer it.

We have Federal privacy legislation here and in the US they have Federal privacy legislation in the financial sector.  So I should be able to call the toll free number on the offer to opt out of all future mailings.  But as many of you have experienced with some of the more aggressive organizations that fill our mailboxes with unsolicited snail mail, sometimes those requests get lost...or expire.  Being a privacy advocate when it comes to unwanted messages, I don't hesitate to call to opt out for offers that include a great deal of personal information like my name and address, plus some fictitious pre-approved credit limit.  I'd say that about half my requests "take", and almost never with those mail-spamming organizations that hit your mailbox every day.

So what does this have to do with data quality?  Well MBNA has a huge data quality problem.  Every month or so they send me a new offer.  Unfortunately, my name is misspelled, reversed, or my certification is used as my first name or last name.  And since their heavily touted opt out application only allows the opt out of a specific spelling of a first name, last name. street address, city and postal code, I can't stay ahead of them. 

With MBNA, I'd have to know all the potential spellings and name-calling they'd attempt to opt out a head of time.  I can't opt out an address.  So between my husband and me, they have lots of combinations to try before they finally hit all the permutations of Karen, Karena, Karin, Kay, Lopez, Lopes, Loper,  ISP, I.S.P., etc.

Can't I just throw away the offers?  No, because I have to shred them due to identity fraud.  Can't you just shred them an be happy?  No, because if they can randomize my name, what's to stop them from randomizing my address? Why is this important to me?  Because their constant filling of my mailbox with open invitations to anyone to fill it out and send it in, then watch my mailbox for the return card is an attractive nuisance that I can't seem to stop or mitigate.

Suzanne, whom I spoke with today, tells me also that MBNA has no Privacy Officer, no ombudsman, no supervisors working, only one phone number, the one printed on my offer, and no other people who can ensure that their data quality problem is addressed.  Oh, and she informed me that they have all the rights in the world to collect data from anywhere, any time they want.  She specifically mentioned that they get information from catalog requests, buying something in a store, or ordering magazines.  So perhaps I'll just stop ordering catalogs and ordering magazines. 

Or maybe I'll just keep calling them, seeing what story a customer service rep can make up every week.  And I definitely don't what to have a credit card or a line of credit with an organization that has such bad data quality during the sales process. I mean, if their systems randomly change my name, wouldn't they randomly change interest or charges or other transaction?. As I remind everyone: 

They will never treat you as well as they did while trying to close the sale.

By Karen Lopez on Friday, June 02, 2006 8:38 AM

I wrote a whitepaper titled:  Enterprise Data Management: 7 Mistakes You Can't Afford to Make.  In this document I cover the most critical mistakes made by data management professionals and how to mitigate those risks. 

This paper is downloadable (registration required) from the Embarcadero website.

From the executive summary:

Today’s information technology professionals are faced with a variety of challenges including legislation, organizational change, and the rate of technological innovation.. In our experience most IT professionals in organizations initiating an enterprise data management program can feel overwhelmed at the scope and complexity of initiating new methods, tools, and techniques.  They are eager to deliver the benefits of well-managed enterprise architecture but have concerns about possible missteps along the way.   Whether their organization is just starting out or experienced in enterprise data management efforts, there are certain pitfalls that can become obstacles to success.

Before we talk about the pitfalls, though, we should discuss terminology. An enterprise data management program is the management of information in a manner that:

• encourages a practical balance between enterprise and project points of view,
• contributes to the development of an enterprise data architecture,
• enables IT groups to respond more quickly and effectively to business needs,
• delivers information that is the most useful to the business, and
• uses the proper tools and techniques in delivering project outcomes.

Enterprise data management includes the use of logical and physical data models as a key component of enterprise data architecture.  These models form a knowledge base of data and information requirements in the context of the business as a whole. 

This paper first looks at the benefits of an effective enterprise data management effort.  Why, if there are pitfalls, should an organization approach data management with an enterprise point of view?  Let’s start first with the reason information technologies exist—to enable businesses to accomplish goals that would be nearly impossible with manual processes.   Enterprise architectures allow teams to improve communications, reduce and better align information technology expenditures, and develop better project estimates and plans.  However, the most important benefit of an effective enterprise data management program is that it instills a greater confidence in the information technology group’s ability to deliver solutions to the business.

The second section of this paper discusses seven common mistakes that organizations can make in developing an enterprise data architecture.  These mistakes each have a cost that negatively impacts projects and the information technology group as a whole.

---

 

By Karen Lopez on Thursday, June 01, 2006 4:56 PM

Peter de Jager writes in his recent article about what is a profession:

That’s part of what belonging to a profession means... a group of people who speak the same language, have access to a common body of knowledge and understanding, and have the ability to communicate this joint understanding to others outside of that circle of expertise.

Further in, he says:

While I'd hesitate to suggest that we have ‘officially sanctioned’ definitions of buzz words (who would decide?), but it should be obvious that we at least agree to stop using buzzwords as if they had an agreed upon definition.

Good question, who would decide.  Right now we professionals sit back and wait for vendors to decide what terms will be used, what they mean, and how they should be used.  Think about what your definition of domain is.  I'd bet we all have different meanings.

But the answer to who would decide is us.

My response to his column was:

> who would decide

 

Well, if we followed other established professions, a professional body, constituted by legislation, would decided.  This body would determine the Common Body of Knowledge (CBOK) and Standards of Practice (SOP).  The latter would be the process and application of the CBOK.

 

This body would also set ethical standards in context of the profession, and would convene hearings when the ethical or professional standards were violated.  It would publish these failures, often with names, to ensure public confidence in the profession.  The body would have its first priority to the protection of the public, not to its members.

 

And we are anywhere near that state.  We let vendors set de facto standards (because we certainly aren't), we let anyone declare a practices as a standard (because we aren't) and we do everything possible to hide our failures (except for Robert Glass).

 

I recommend finding and reading the IEEE document "A Mature Profession of Software Engineering" http://www.sei.cmu.edu/publications/documents/96.reports/96.tr.004.html for the work they did in comparing the IT industry with established professions.

By Karen Lopez on Thursday, June 01, 2006 2:41 PM

Thanks to the great people at O'Reilly, I am able to publish the excerpt for Chapter 1: Introduction to our Data Modeling Group.  To download the chapter, log in to the board and go to the Data Management Resources conference, Database in Depth topic.  A PDF file of the first chapter is attached to my posting.

Discussion of the Foreward by Jonathan Gennick, the preface, and Chapter 1 starts on Monday.  Get reading!

 

By Karen Lopez on Thursday, June 01, 2006 5:27 AM

Sign up for a free trial of Safari Books Online and get access to many IT books for two weeks - FREE!.

Our book study topic, Database in Depth, is also available.   Please note that if you have purchased the book, there is an offer within it for a 45 day trial -- another great reason to buy this book.

Try Safari FREE for 14 days

The link above is an affiliate link, but because we are based in Canada, we don't get any payment.  Hopefully, O'Reilly will offer their affiliation program to Canada soon.