A lot of the jobs I’ve applied for request experience in ‘‘database management.’’
What, exactly, does this mean? Judging by the job descriptions it has to do with monitoring/tracking ongoing office activities. Is that like administration?
More to the point, what kind of activities in my history would demonstrate that I am capable of this?
-Research experience? (Measuring and entering the result into an excel database, performing statistical analysis on the dataset using SPSS.)
-Administrative experience? I once maintained over 800 active accounts for a consumer credit counseling agency. It was a bit more complicated than your standard customer service job (I know because I started out as a customer service rep.) Documentation was key, each client had an individual account with assigned tasks that had to be worked by a certain deadline, and we were all the time making and noting changes to the account - is that database management?
Just trying to gain some clarity here about what these prospective employers are looking for.
Assuming these are social worker type jobs and not tech jobs I think your ‘800 client list management’ would count.
A LOoooooooong time ago I was hired to do ‘database’ management but I was actually building the database* using D-base I think - I don’t even know if jobs like that exist anymore - I think no.
*As in programming the back end to create an easy electronic form for a end user to use. I assume that’s not the type of position you’re applying for.
Database management doesn’t mean whether you can use a database–keying in information and performing calculations on that information are not management activities, they’re user activities. DB management means you know how to make and maintain a database, can design custom queries as needed, and can optimize tables and streamline searches so they return faster results. It’s really not working with data itself, it’s working with the way the data is stored.
For example: when I was an IT major back in the day, we used a program called Visio that you used to logically design the database (it looks flowcharty). We would have to design the DB, decide what data we would store, and create a unique, logical key for each entry in the DB. We also needed knowledge of the DB language SQL to accomplish and design queries (which can get unbelievably complicated with a large database). And we’d use a program like Oracle to manage the DB and input our SQL queries. My knowledge ends there, I dropped out before I learned how to make a GUI.
Without seeing the job descriptions of what you’re applying for, I can’t know whether they would be happy that you know how to input and manage information in an excel spreadsheet, or if they want someone who can design or administer an enormous full-blown database. But the term “database management” is a much more robust field than knowing *how to use *a database or spreadsheet. So if you’re not in the tech field, they’re probably just using the wrong term for what they’re looking for.
A database administrator doesn’t just work with the data in the database.
That sounds more like portfolio management or mutiple account management.
It’s been a long time since I used SPSS in grad school, but what I remember of it was more along the lines of a specialized adaptation of Excel. You also note that you worked with Excel; that software has always had a lot of powerful functions available to mathematicians and statisticians – they just aren’t often accessed by the typical office user. As powerful as those programs can be, they’re not quite databases.
Imagine several tables. You can make several tables in Excel by putting them each on a separate worksheet. You can even make Excel use special formulas that will make it refer to data in one table [worksheet] and have that data affect what goes into another table [worksheet]. The great part is that, if you’re clever enough, you’ll write your own formulas from scratch to make Excel handle the data and the results just the way you want them to come out.
A database is a lot like that, and more.
A database starts with a couple tables or more, always with the categories arranged in columns with the individual data arranged in rows. The agency you worked for undoubtedly used a database with several tables – banks (addresses, phone numbers), client accounts (names, addresses, Client ID’s), creditors (addresses, product types, account numbers, balances, APRs, Client ID’s), Calendars (dates, Client ID’s due dates, holidays), etcetera, etcetera. The management of your agency probably had access to another database with several tables – employee, supervisor, Client – as well as the database(s) that the customer service guys used. The HR person(s) probably had access to a different database with tables for employees, roles, benefits, payroll, etc. The beauty is that a database (when properly created) will tie those tables together in various ways. A database developer will know the types of data in various tables and be able to perform searches and manipulations and write formulas to yield interpretable results. A database developer will know how to make sure certain people can put data into certain parts of the database, and certain people can extract certain types of data from the database.
A database manager (or databbase administrator, or DbA, or DBa) has at least some basic knowledge of how databases are generally structured. There are several types of databases (Rainbow, Oracle, Paradox, MySQL, TransactSQL, etc) and most database managers focus on just a few types.
The main focus of a database manager is understanding what is essentially yet another table that most users and developers never deal with. It’s kind of a meta-table that contains parameters about the tables – user permissions, maximum size, where to store the data and where to store information about ongoing changes, how dates are generally formatted, etc. Database Administration is often the responsibility of the IT department. Management entails controlling who has access to which parts of each database, making copies of databases, reducing wasted space in databases, etc.
There’s a lot of tools out there to help manage databases, and some of them don’t even let you see the data inside. Quite often, the database manager doesn’t even care what’s in the databases. He (or she) just has to create or delete databases, make sure the data doesn’t get lost, doesn’t get ruined, and doesn’t take up all the available computer storage space.
In fact, a database administrator rarely works with the data in the database. He works with the databases as whole entities.
And I feel like a number
Feel like a number
Feel like a stranger
A stranger in this land
. --Bob Seger
. Feel Like a Number
Well, there’s a little confusion here, because what “database management” or “database administration” *usually *means is what people are describing here: actually designing, building, and maintaining a relational database. (And incidentally alice, jobs like that certainly do still exist, although probably not using dBase. There’s actually a growing demand for them, because databases are the underlying foundation of most of the internet.) Building databases is a big part of what I do, and I’m pretty passionate about it. I could talk your ear off if you wanted me to - but you don’t, because that’s not what you’re talking about here.
What many IT-trained people don’t know is that in the non-profit sector (and some other realms), “database management” is the term for basically what olives is describing: data management, from the users’ perspective. In other words, the *content *of the database, vs. the structure. At all of the non-profits I’ve worked for, there were one or more people who were database managers, sometimes in addition to other duties, sometimes not. They didn’t work with the “backend” database (Oracle, MSSQL, etc.), but rather with user interface software based on that database, geared for the specific needs or “business rules” of their organization. They usually didn’t do too much fiddling with the structure or performance of the interface itself, but they did have to understand a bit about how databases work in order to do their jobs well. Their duties entailed things like:
Designing the requirements of the interface and database for their specific organization. While they might not actually build the database, they did need to determine what information was important, and where and how to store that data to best make use of it. For instance, a donor to the organization might ask to be put on the newsletter mailing list. You could just make a note in a general “comments” text field on the donor’s record, but that would make it really difficult to identify that person later. It’s much more efficient to have a “mailings to recieve” field, with codes for each item. But if the donor writes a note to say, “I really enjoyed your last newsletter on climate change!” it would probably make the most sense to store that as a comment. Even then, though: can it just be a general text field, or do you need to have a separate date for each comment entered, so you can review the donor’s correspondence history? That kind of decision would be up the the database manager.
Creating and enforcing standards for proper data entry. There might be a bunch of data entry people whose job is just keying in data. But if they don’t enter it carefully, it makes it a lot harder to get it out again and make use of it. So for example, street addresses might go in the “Address 1” field, and apartment numbers in “Address 2”. Something like that might seem trivial, but if the fields are reversed, or if everything goes in “Address 1”, then searching for a given address or sending a letter becomes much more complicated. The database managers would also create levels of permission for data access. Some people might be able to view only certain pieces of data, or might only be able to add new records. Others would have the ability to alter existing data, or even combine and/or delete records. The database manager would have to understand what effect each of these actions can have on the data, whether the action can be undone, and if so, how difficult that would be.
Retrieving data and performing statistical analysis. This is probably the biggest portion of a database manager’s job. Sometimes, it’s as simple as exporting a mailing list to Excel, but usually, it’s something more complex, like tracking the behavior of a specific group of people over a certain period of time. Let’s say you wanted to take a detailed look at the teen moms who have come to your organization over the past decade: what services they received, what their outcomes were, etc. You need to know how that information is captured in the database, how to pull it out, and how to make sense of it. And you need to not only know how to run a report in a mechanical sense; you also need to know the logic that goes into that report. How is a “teen mom” defined, in your data? Are there some people who meet all the criteria for being a “teen mom”, but must be excluded for some other reason? And of course, this also depends on doing 1) and 2) right - if you haven’t organized the storage of your information correctly, you’ll have a hard time getting it out in a usable form, if at all. And if it’s been entered or handled incorrectly, you can’t trust that the numbers you’re calculating accurately reflect reality.
So in short, the database manager has to have a clear understanding of both the database and the data: what information they have, where it is, what it looks like, and how to make use of it.
Now, if you asked the people at the company who housed their data, and who built the user interface, they would say, as rachellelogram says, that these people aren’t “database managers” at all, they’re just “users”. From an IT/computing perspective, that’s true. But this is indeed what this kind of job is called in some sectors.
And I would say, therefore, that your experience with the consumer credit counseling agency is very relevant (I *assume *you were working with a computer program and not just paper files, right?), as well as the SPSS stuff. I find that some employers also just want to know that you can learn and use different software programs correctly. Because even if you understand both the structure and content of your data inside and out, if you can’t navigate your way through the software, you’re useless. So if you managed those 800 accounts with some kind of computer program, say so, and explain the different tasks you had to do: entering and updating client account records, documenting actions taken by the agency and client responses, running daily action reports, etc.
Okay, enough rambling. I hope there’s something helpful for you in here. Let me know if any or all of this doesn’t make sense, or if you want to know more (“good god, there’s more?”).
No. SPSS is a specialized statistical data analysis tool which was originally designed for people who needed high-concept stats work but didn’t specialize in it (the initials SPSS stand for Statistical Package for Social Sciences, in fact. Technically speaking, SPSS doesn’t exist anymore–after IBM bought it they changed its name to PASW.) More to the point, SPSS isn’t actually a spreadsheet. You can only do very limited “spreadsheet” functions with the program. You can calculate a field, but only in a very limited way. You can’t have multiple sheets in a workbook, a function which spreadsheet programs have had for over 25 years. You can’t sort by more than one variable at a time. What you can do is run binary regression, hierarchical linear modeling, Pearson’s correlations, and hundreds of other stats equations on your data.
I work in Excel and SPSS/PASW every day. When I need to analyze data, I’ll pull the data from our main database into an Excel spreadsheet and do all my cleanup work there. Although cleanup is slow in Excel, it’s simply not possible to do in SPSS/PASW. But after I upload the data into SPSS/PASW, I can do my modeling work very quickly.
As for database management: I’ve been moving into database management and design over the past couple of years. I’d definitely look into learning SQL, VBA, and other languages as needed–I’ve been doing that myself. But I too work in the non-profit sector and I’d agree with Heart of Dorkness that “database manager” in this sector does mean something more akin to “data management.” Most of us work with proprietary databases because the cost of even sharing a DBA with another department or non-profit is too high. If something goes wrong with our database, for example, we need to call down “south” to get them to fix it. Now, part of the reason I’m moving into management and design is that our database company, bless their heart, has been mainly concerned with liquidating their competition than actually fixing the problems with their program.
That, and I just got asked yesterday to put together a database for a soup kitchen run by some local nuns. Are you going to say no to the nuns? Me neither.
I’ve spent over 30 years trying to avoid databases, but now I’m smack inside of them. I’ve built a database and designed a schema for a large one, but I’m nowhere near being a DB Manager. Besides the issues of storage management and security mentioned, databases can also be optimized for particularly common queries.
BTW, EXcel is not a database. Not anywhere close. It handles data, yes, but databases allow access by many people at once, and have particular ways of storing relationships and getting data out through queries. The Microsoft database product is Access. Most of the people I know who are good with databases hate, hate, hate spreadsheets.
My employee workplan lists the qualifications needed to do my job. One of them is database management.
But I’m not an Access or SQL guru. I knew a teeny tiny bit of Access when I was hired, but no one asked me in the interview to demonstrate my expertise. Almost everything I’ve learned has been on the job. I know a lot more than I used to, but I still have to rely on google to get my SQL code to work.
Unfortunately, it seems to be one of those skills that you can’t really teach yourself well. You need real world problems to really understand what a “query” is. I tried to teach myself when I was hired, thinking I was gonna be up shit creek when they realized I didn’t know what the hell I was doing. But all the materials I could scrounge up were not really helpful. So I just learned by combining googlefu with good old fashion stubborness. I hate not being able to “fix” something when I leave work–so I’ll fiddle and fiddle until I learn.
It’s definitely is a good skill to have, and I lucked out that my employer wasn’t looking for an expert right on the spot (which may be the case for the employers you’re interviewing with, depending on the job). If you can find a way to learn something, even if it’s just how to run a query in Access, then you’ll at least be able to put that down on your resume.
The term is essentially devoid of a “true” meaning.
Generally the rest of the job posting should give you some idea, and what type of job it is. If the job title is something like: DBA, Systems Analyst, Software Engineer, Database Developer, Computer Programmer, Programmer Analyst or such then most likely if it says “database management experience” it means you’ve actually created databases and maintained databases in an enterprise setting. Meaning you’ve can created database objects (stored procedures, tables, views, functions, triggers), and that you have done so with some mainstream enterprise type database (Oracle, DB2, MySQL, SQL Server.) The rest of the job posting will imply a very technical position, meaning basically you can do very high level manipulation of databases, write scripts to create database objects, and you have a deep understanding of how relational databases work and how to write queries (and to not write queries that can lock the database up because you’ve accidentally done something that is going to return 10 billion records.) Often in the job requirements will be a B.S. in some technical field such as computer science, computer engineering, information systems or etc.
If the rest of the job isn’t like that, it may just mean you need to know how to say, occasionally work with an Access database or some sort of simple GUI that the enterprise has that is a front-end for an enterprise database. When I worked for the Commonwealth of Virginia everyone from social workers to field biologists might have to do some “database management” but it really just meant they could work with a more “metaphorical database” in that they could catalog and file information and learn and understand the specific system being used to do that. It didn’t mean they needed to be capable of optimizing batch jobs and designing a set of relational tables to nth-normal form.
As a Commonwealth of Virginia employee, I think you are right. I think that’s why “database management” is on my EWP. Not everyone has to enter or pull data out of the state database, but pretty much all entry-level employees do at one time or another. Only folks who have titles like “database manager” are expected to manage an actual database that is accessed by other people. The rest of us may have our own personal databases, but that’s different. I think “database management” is a fancy way of saying “knows how to work with data”. Depending on the nature of the job, that could be everything from collecting data to performing advanced statistics.
To echo what Voyager said, I’ve found that people tend to fall into two camps. Excel/SAS users or Access/Oracle users. There’s not a whole lot of cross-over between the two, because the programs provide totally different functions. The database manager in my office, for instance, is an Access guru but rarely ever touches Excel. She doesn’t know what an array formula is, nor would she ever need to. On the other hand, I use Access only when I need to organize and store outrageously huge datasets. Like merging ten different spreadsheets, each containing 50000 records. I would never use Access for calculations unless I absolutely have to because I consider Excel (or R, depending on what I’m doing) to be the “go-to” tool for that, even if I thought I could write a query in Access that could do the same thing. It would just take me longer, with lots of trial and error.
Before they expanded the row limit to Excel, I used Access a lot more than I do now. Purists probably go “tsk tsk tsk”, but I’m all about using the tool I know how to manipulate best.
Just to be nitpicky, Access is a local, personal database and GUI tool. Not used for larger applications although it can be rigged up to work with more than one user. The MS database used in corporate and enterprise levels is MS SQL Server. Supports many simultaneous users, connection pooling, rapid connect/disconnect for web and app server uses, Replication services, Reporting services… the list goes on and on.
Or, if they work in SAP, “superusers” if that is part of their job duties and the rest is more “real world oriented”, and “functional consultants” for those of us whose job consists of translating “what end users want” into “what the techies understand” day in and day out. Given the kind of work you do, olives, I imagine what the ads want is what I’d normally call a superuser: someone whose job is mainly done outside the database, but who doesn’t think of it as some sort of (probably dangerous) black box and who can translate from Userish to Techish when needed.
The really bizarre thing I’ve seen is that you see some hugely underqualified DBA’s on the market because some non-technical executive assistant somewhere got tasked with managing some administrative Excel spreadsheet, which their clueless management kept calling a “database”. So the title gets elevated to “database manager”, and clueless management thinks the next logical step up is “database administrator.” Which, fine, but this is not the same caliber of DBA as someone with a technical education who intentionally pursued a technical career. So when you talk to a DBA, at first blush you can’t be sure whether you’re talking to someone who can rip apart an underperforming query, or just someone who lucked into a cushy job because they’re historically close to the data.
1,2, and 3 are exactly what I did at my last non-profit job. Now how do I nail that in a few bullet points for my resume? For now I call it database management but explain pretty clearly what that does and doesn’t mean during interviews.
Well, for one thing, what kind of jobs are you applying for now? If they’re not in the non-profit world, then you might want to call it something a little more specific, like “donor (and/or client, etc., as appropriate) database management” or “donor data management”.
For your bullet points, I think you can more or less use the first sentence of each of my items, tweaked for tense and clarity, and fanciness. Something like:
I also put them in descending order of where you probably spent most of your time.
FWIW, I have learned more about this now. At work we’re in the process of acquiring a donor database management system (SalesForce, Raiser’sEdge, etc), so I’m excited because, as Development and Outreach Coordinator, I’m going to get database management experience. In the non-profit world, this means retrieving donor/foundation data via queries. We’re trying to find the right program for our needs. Next week we’re going to audition something called Results, and I will learn a bit more about queries then. I am truly looking forward to this because I will be learning not only how to manage a database, but how to implement one.
That’s awesome, olives. You seem like a person who will really enjoy this stuff. As I mentioned, I’ve worked with a number of donor DBMSs, including Results Plus and Raiser’s Edge, both as a client and as a provider. It’s been a couple of years now, so I don’t recall too many specific details about any particular system, and I’m sure they’ve all upgraded umpteen times since then. But if you’d like some ideas about how to assess your org’s needs and evaluate the systems available, or how to write queries, I’m happy to help. Feel free to PM me, and I’ll write you a novel.