November 28, 2007 at 12:09 pm
Trying to decide whether or not the responsibility of creating the data model should reside within the applicaiton development team or the database administration team.
Any personal thoughts, examples of company organizations where you've worked, any preferences anyone has and why would be greatly appreciated!
Let the debate begin 🙂
November 28, 2007 at 12:24 pm
Heaven forbid that you should leave it up to the application developers. They'll design you a database that makes a DBA job a nightmare! And there are people who argue that a DBA should not be touching the data model because they'd make it too technical and not at all relevant to the business model.
A lot of places are actually sourcing that to a specific job title. The Data Architect (or Data Modeler) is usually the person who takes care of that job. Whether he sits in the app Dev team or the Database team is of no import. This position requires someone who understands the soft skills of a Business Analyst and the basic relational database skills of a DBA.
Usually the Architect won't be a "techie" because you need someone who can do both the logical & physical. I've recently learned (from work experiences) that a logical model tends to look nothing like a physical model.
It's up in the air. My personal opinion is it should be someone who understands BI and isn't a developer / DBA primarily. At my workplace, we have a Data Steward who is responsible for maintaining current data models, but he has a data modeling background also.
November 28, 2007 at 12:32 pm
I agree most people tend to have someone whose job it is specifically. Although in small houses it depends on who has the best knowledge the DBA or an App person. I am Application developer for the most part but I tend to handle my own data modeling and would not trust my DBA to handle it, however we have a data modeler who is coming in for a large scale rewrite of two of our older applications (I inherited a lot of code and no time to do by myself) and I am happy this is going on as I can spend more of app design and let her worry about data integrity, but she is also willing to listen to design comments when I see issues so it will work great. But I would see what your people really know before you make a permanent decision and consider seperating whomever into that job responsibility itself so it is defined and not grey.
November 28, 2007 at 1:41 pm
That's easy... it would be the person with the most to loose if the design is bad 😉 That's the only way someone will be interested enough in doing a good job 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
November 28, 2007 at 1:51 pm
Jeff Moden (11/28/2007)
That's easy... it would be the person with the most to loose if the design is bad 😉 That's the only way someone will be interested enough in doing a good job 😛
Well except for the BUSINESS OWNER who might know squat abot SQL 😀
* Noel
November 28, 2007 at 1:59 pm
I guess my thought would be - why does it have to be just ONE person's issue? The business owner has all of the rules, the designer has the project scope and prototypes, and the DBA has the SQL savvy. I'm not sure you can leave anyone entirely out without severely compromising the project.
At very least it should be some form of "code review": the business owner and the designer sit down and hammer out the requirements,etc... Designer turns it onto a functional requirement document, with use cases and a data model attached, and then needs to present it to the DBA for an understanding of how this should interact with the existing architecture.
And - i wouldn't necessarily go as far as saying that your developers will wreck your DB. Just scare the cr@p out of them a few times, and they churn out pretty good models. Especially if you lock them out of their systems until they come up with something that won't "kill" the server (my predecessor used to do that).
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
November 28, 2007 at 9:01 pm
I guess my thought would be - why does it have to be just ONE person's issue?
That's the real key... it shouldn't be. You've hit the nail on the head on all points in your post.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 29, 2007 at 4:05 am
I actually agree with getting everyone to sit down and contribute. The problem is that in practice it usually ends up being one person who sits down and creates / maintains the actual file the model is being kept on. If it's a team responsibility, people get busy, assume someone else is taking care of the issue and suddenly a year down the line, your model is out of date.
Having lived through that myself, I think you really do need to assign a point person to get everyone in the same room, to facilitate the discussion necessary for the reviews, and to motivate someone's butt to actually maintain the model. Otherwise, you've got nothing.
November 29, 2007 at 6:39 am
Brandie Tarvin (11/29/2007)
I actually agree with getting everyone to sit down and contribute. The problem is that in practice it usually ends up being one person who sits down and creates / maintains the actual file the model is being kept on. If it's a team responsibility, people get busy, assume someone else is taking care of the issue and suddenly a year down the line, your model is out of date.Having lived through that myself, I think you really do need to assign a point person to get everyone in the same room, to facilitate the discussion necessary for the reviews, and to motivate someone's butt to actually maintain the model. Otherwise, you've got nothing.
That is what we have in our folks, a point person, someone who knows the rules and works with us to determine the design but they have responsibility for it being maintained and controlled.
November 30, 2007 at 7:09 am
This is one of those things Computer Science departments usually don't teach, but should. Namely, managing and developing a code/data design. A course I took in college from an aerospace department taught me more about system and code design that I was ever taught in my CS classes.
My opinion is that a data model should be designed by someone knowledgeable in database design, but the important thing that your question doesn't even address is the interface between code and data. DBAs shouldn't be worried about the underlying code design of the application, and an app developer shouldn't be worried about the underlying data design. What you need to define is a common interface that both sides will use, and what is expected to come out of that interface, or be put into that interface. It doesn't matter what someone does on the database side, as long as it conforms to the interface specification, same on the app side.
I really suggest you read this book:
"The Secret of Apollo: Systems Management in American and European Space Programs" by Stephen B. Johnson.
Systems Management is so much like designing computer software that it is uncanny. For those of you familiar with Object Oriented Design, you will see a striking resemblance to Systems Management. The key is, it doesn't matter what one individual component does, just that they are speaking the same language between them, that language is strictly controlled, and both sides are expecting the same things to be coming out of that conversation.
November 30, 2007 at 7:35 am
Data model - I suspect everyone, so far, has been talking about the physical data model. My vote then is for the design DBA. However, if you are talking about a conceptual model - then it is a group, business, operations, application, DBA and GUI. Logical model is more in the realm of a Data Architect or modeler who is interested in not just the current application but the enterprise business needs as well as a good understanding of data modeling. Once the logical model is completed then the data architect passes the model to the DBA who will then transform it into a physical implementation. If only one person is doing this then it is best to have three hats and try not to get too physical in the business scouting/research.
I cringe whenever I end up having a DBA in an intial business design session because the DBA invariable wants to discuss the length and data type of each possible attribute despite being told that we are not at that level of detail yet...:-)
November 30, 2007 at 7:54 am
mgerszew (11/30/2007)
My opinion is that a data model should be designed by someone knowledgeable in database design, but the important thing that your question doesn't even address is the interface between code and data. DBAs shouldn't be worried about the underlying code design of the application, and an app developer shouldn't be worried about the underlying data design. What you need to define is a common interface that both sides will use, and what is expected to come out of that interface, or be put into that interface. It doesn't matter what someone does on the database side, as long as it conforms to the interface specification, same on the app side.I really suggest you read this book:
"The Secret of Apollo: Systems Management in American and European Space Programs" by Stephen B. Johnson.
You're inadvertently paraphrasing Codd's 12 rules, which are some of the fundamental principles for Relational Databases. See here:
That being said - I still get leery of the chinese box syndrome, where the data folks and the app folks just don't spend enough time communicating. The DBA should be A LITTLE "worried" about what happens in the code, and the app guy should be A LITTLE worried about what's going on in the data layer. An Interface (as defined in OOD) is fine and nice, but it's not enough info to allow the data side to really "sing". It's good to know what you send in and what you get back, but frequency, size and characteristics of HOW the data is used are fundamental aspects in how you build the data layer and data access.
So - keep the roles distinct, but not ignorant of each other.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply