Browsing articles tagged with " Backup"

5 Naughty and Nice Ways to Love Your Data

Feb 14, 2013   //   by Karen Lopez   //   Blog, Data, Data Governance, Data Modeling  //  1 Comment

photo.JPG

It’s Valentine’s Day evening in North America.  I’m guessing that means that you and a loved one are waiting for a table at your favourite ChiBeeFridayGardenTM.  Hopefully you’re not sitting in a crowded bar drinking sugary sweet margaritas that never came anywhere near a lime or real tequila.  But if you are, that also means you’re probably munching on some free chips and salsa.  Bueno.

As you know, I’m a data advocate…a data evangelist, even.  That means I want you to take care of your sweet snookums of data that you’ve entered into a commitment to love, honour and obey until the end of time.  Or at least until that next recruiter call comes.

So while working flying across Canada in my cubicle in the sky, I came up with these 5 tips for ensuring that your data feels loved, safe and warm.

1. Try some constraints.  I’m tired of seeing systems with no foreign key (FK) constraints or indexes on the data.  Vendors are especially straight-laced with their “we do all that enforcement in the application” answers as to why they don’t want to constrain their data.  That’s a subject of a future post. However, too many database designs lack even the most basic data quality rules.  There’s a whole lot of things we data professionals know about what makes for good (or good enough data).  Enforcing those rules as close as possible to the data is the best way to protect to that data.  To make it feel loved because it’s safe.

2. Be free. Don’t worry about backups.  What? No backups? No, that’s not what I said.  Don’t worry about backups; worry about restores.  You can have a perfect backup strategy in place and still not be able to restore because you’ve never tested that critical part of the process.  Sure, to restore there has to be a backup first, but too many people set that up and don’t realize that there’s another process out there deleting the backups, or destroying the tapes, or worse.  While you are at it, make sure you are monitoring the backups to see if they are actually working. Regular (and hopefully automated) restore testing will quickly point out failures in the backup and the restore strategy.

3. Put your data on a pedestal. I support systems with data that is more than a hundred years old. Over those decades, that data has been passed around between databases, systems, spreadsheets…well, you know how that works. Every professional who put their hands on that data had an opportunity to nurture it or to turn it into the broken, barely human data crying in a relation’s arms. There are certain data practices that make data less usable, less accurate and less strong. That weakness in the data translates in a general weakness in the entire system. That then translates into business weaknesses. Data last much longer than code. If you are optimizing database designs for the code, you may be harming it in a way that it can never love you back. Love it even on fast and agile projects.  Just enough design doesn’t mean no design; it means just enough to love it right.

4. Get familiar your data. Almost to the point of stalking it. You need to not only understand the structure of a database, but also what data is in it.  I can’t tell you how many times I’ve seen someone reverse engineer table and column names, then use only that information to analyze what data is contained in the database.  Big mistake.  Want to be surprised?  Go look at a bunch of columns called Notes or Description or Address Line 4 and see what you find.  I’d bet you a bag of naughty candy hearts that you’re going to find a brand new set of data that few people knew was held in that database.  You might even find credit card data, tax identifiers or insulting customer comments buried there.  I’ve seen all of that.   Data profiling is something you need to do for the life of a data structure.  Misuse of data structures happens more often than you think.

5. Cozy up with your team members. If you are data modeling or designing databases and you aren’t physically next to the people working with those designs, you’re missing out on a hundred opportunities a day to answer their questions, overhear their debates about the difference between Department and Division and generally not providing support for the project you delivered to them.  What? Those people work thousands of miles away?  You need to build a long distance relationships via Skype or GoToMeeting with these people.  You might even need to answer their questions in the middle of the night.  Just like in real life relationships.  The key is to send a message of availability and wiliness to help.  I’m pretty sure I’d better stop this analogy here, but you know what I mean.  You say your boss pulls you off a project as soon as version one of the data model is done and puts you on another one right away?  Well, there’s a name for that type of a boss.  I’ll stop here, too.

Your data really isn’t your data.  It belongs to your business users and some of it to customers.  When you don’t love your data enough, it knows.  And others will know, too.  So spend some time tomorrow ensuring that your data is loved, safe and warm.  It will do the same for you and your team.

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