I’m looking for some advice. I’m a Taxonomist/Indexing at a Financial Services company. My responsibility is to design and maintain a taxonomy used for the research produced by my company. I’ve recently been asked to be involved in the Database design phase of revamping our current research platform because of the analytics deliverables I’m responsible for out of the current application, as well as my information management background. Usually, the business would work with a Business Systems Analyst in IT who would take down our requirements and then propose the best solution. For reasons I won’t get into here, the business has decided that they want to be the ones to choose and create the data architecture model for the revamped database. And when I say create, I mean write up the ERDs and literally design out the database structure.
My question is: Are there resources I can use to educate myself on the interplay between Taxonomy and Database Architecture? Are these two things closely interrelated? Can knowing about their interrelation better help me make a better decision on the final architecture model?
Any and all thoughts are appreciated, as I’m pretty new in this space and am looking to learn as much as possible.
Capital Group Company
Database structure and taxonomy are pretty far apart. There are courses that you can take to learn how to do database design but it’s a pretty radically different set of thinking and I’d generally not recommend a taxonomist — even with training — attempt a major database design first thing.
Let me give you some background and context so my comments make sense. I grew up in the IT world. I’ve done development, database design, and infrastructure management at a variety of small and large organizations. Development in a traditional procedural or object oriented procedural language is one way of thinking. (It’s roughly like writing rules for automatic classification.) Database development (query development) is a set-based thinking that is completely different thing. (There’s no good analogy on that taxonomic side to match this.) I evolved into doing information architecture because of work with SharePoint and trying to make information more useful.
The real problem with doing a database design without experience is that your ultimate goal is to make the queries easy and efficient. It’s hard to know what will and won’t be easy until you’ve lived it for a while. So you can get to a technically accurate solution but one that makes it hard to get the results you want. There are a few database design/structure courses up on Pluralsight.com that you could do to see what you think about it. (They have a free seven day trial.)
I understand there may be factors that are preventing the use of the internal resources for developing the database architecture, however, I would suggest that if possible you engage someone with the background in database design to help.
I wish I had a better answer for you.
Thor Projects LLC
What Robert Bogue says is very true and you would be well to heed his advice.
Taxonomi and Database design sounds like two different areas, but thinking about what you have written – it’s perhaps not that different. For me, it’s all about finding patterns and structures. In a Taxonomi you are perhaps a bit more interested of the data itself, from a database design point of view data is not important (if you have an object/table like CARS the database designer is more interested about the properties where working with a a Taxonomi i think you are a bit more interested about what kind of cars it can be, for example Volvo, SAAB, Fiat, Ford etc – at least I think so).
An ERD diagram is of course quite a concrete thing and they have their own lingo (What is an Entity Relationship Diagram) which of course is a bit challenging in the begining, but it’s not Rocket Science.
So where to start? Learning from my kids i’m now a big fan of learning from youtube and there are good starting up videos like; Relational Database Concepts
I think starting out from the very beginning in a new area is always hard since the big picture is not clear. However the only way is doing like you do, start asking questions. At AIIM2018 they arranged something called “Braindates” where people could connect in real life. With the help of computers and all the current communication tools, we all are able to connect and communicate regardless of distance. I’m always happy if i can be of any use and arrange a skype/webbex session to share would be not problem for me.
Best data regards
Megan, it sounds like your company is about to make a big error.
As Robert said, database design is an expert job and most developers get it wrong, too.
Poor database design that doesn’t anticipate the future queries and the data volume adequately will lead to poor application performance.
What I would propose is that you define data requirements. You could even define a high level (conceptual) data model (i.e. your business objects and the data items you need to implement those). I guess that would be feasible in short term with your Information Management background.
However, I strongly advice to leave the canonical and in particular the physical data model (which depends also on the database product) to a developer or get a consultant in.
You risk to spend a lot of time and money on tuning your database and redesigning your application if it ever flies.
It’s a complex matter and I only scratched on the surface but I hope you manage to convince your management to get experts on board if you don’t have them in the team. They may think they can do it cheaper than others but they will regret that bitterly afterwards.
As a 20+ year IT veteran who has been a BA, PM, PgM, Solutions and Enterprise Architect, and management consultant, I agree wholeheartedly with Robert and Ulrich. To produce something that your business can rely upon for stability, accuracy, and performance, you need someone that has spent time learning from the ground up in this area. Especially given that 2 major axes need to intersect here:
. The physical and canonical DB design for storage and retrieval
. The fact that this database is actually going to be storing a different type of data from a ‘traditional’ transactional DB, namely unstructured data/content
Doing this competently is definitely something you need to work up to over time!