Where’s your database’s ER Diagram?

I was recently training a new software developer, explaining the joys of three-tier architecture and the importance of the proper black-box encapsulation, when the subject switched to database design and ER diagrams. For those unfamiliar with the subject, entity-relationship diagrams, or ER diagrams for short, are a visual technique for modelling entities, aka tables in relational databases, and the relationships between the entities, such as foreign key constraints, 1-to-many relationships, etc. Below is a sample of such a diagram.


I. The Theory

Like many enterprise technologies, ER diagrams can be a bit of an overkill in single-developer projects, but come in handy as soon as you need to explain your design decisions to a room full of people. Since a software application is only as flexible as its underlying database, ER diagrams help define the initial set of business rules for how people will be able to interact with the system. As a software development practice, they are often encouraged, but in medium to large companies, they may be absolutely required. There are enough tools now to create ER diagrams quickly and easily, many of which will generate SQL database creation statements for a variety of platforms directly.

II. The Practice

Due to tight time constraints and ever-expanding scope creep, I find most developers skip creating or maintaining ER diagrams whenever the opportunity arises. One telling example of this is a developer who creates a diagram, starts building the application, and realizes their initial diagram was completely flawed. Given that they are now behind schedule because they made mistakes in modelling the data, they do not have time to go back an update the model, and their ER diagram becomes a distant memory compared to the final database. Most managers would rather see finished software products than accurate diagrams, although will take both if offered.

ER diagrams are incredibly useful in the early stages of designing a new application, but as an experienced software developer, I spend more time enhancing and maintaining databases than I do creating them from scratch. Furthermore, it can be difficult to create an ER diagram for an existing database, especially if you were not involved in its creation. Even when companies do maintain ER diagrams, they tend to be months, often years, out of date, as it can be difficult to motivate each and every software developer to update the database documentation after making a change.

III. Where’s your database’s ER Diagram?

What about your software application? Is there now or was there ever an ER diagram for your company’s database? Is it 100% accurate to the current production database? I’d like to hear from other developers to find out if people are diligently maintaining ER diagrams, or if it is really a common practice to let them fall by the wayside after a database is established.

jeanne’s oca/ocajp java programmer I experiences

Today I passed the Java SE 7 Programmer I with a score of 98% which makes me a “Oracle Certified Associate, Java SE 7 Programmer“. (see other post for Java 8 exam)

Deciding to take the test

If you’ve been following this blog, you may know that I’ve been a Java developer.  (tech lead and architect count if you still code <smile>).  Last year I took the SCEA and Core Spring certs.  So why go back and take the “entry level cert.”  I’ve thought about taking the SCJP twice.   My thought process to finally getting here:

  1. Bert Bates mailed me a free copy of K&B version 5 so I could help spot plagiarism of questions on BlackBeltFactory years ago.  I read the book then.  I learned a lot.  I scored poorly on the sample questions because I didn’t take any time to memorize the  relevant information.  And I didn’t care to spend the time learning obscure details.
  2. In 2009, there were rumors of the Programmer Plus exam.  If that exam existed, I wanted to take the beta of it because it sounded *so cool.*  I re-read K&B version 5 and actually studied APIs.  The programmer plus never came to be and I wasn’t motivated to take the traditional SCJP.
  3. A year or two ago, I was one of the cadre of JavaRanch moderators providing technical review of the K&B SCJP 6 mock exam book.  Reviewing that book actually made me less likely to want to take the test because I read it questions about obscure details.  (It did make me interested in doing technical reviews of future books though.  I actually did one for a yet to be printed Manning book – The Well Grounded Java Developer.)
  4. When I noticed the Java 7 OCJPJP had JDBC and NIO sections, that got me interested again.  JDBC is one of my favorite topics and I moderated the CodeRanch JDBC forum for many years with Scott Selikoff.  The beta of part 2 was only $50 so I decided to take it.  I decided to take it on 4/19 and took the beta on 5/9.  I’ll be blogging about this separately in the next week or two.  While I don’t have the score yet, I think I either passed or came really close.  If I fail, I’ll pay full price to take it again.  I’m never going to be more prepared for it than I am right now and don’t want to learn obscure details again!  Once I realized this, I needed to take part 1 of the Java Programmer exam to actually get certified.

My study plan

In all fairness, most of the studying went on before I decided to take either exam.  Both by reading/reviewing the SCJP books and by just picking things up over the years.  I had a week and a day between part 2 of the exam and this part (part 1).  For two of those days, I didn’t do anything at all.    What I did the rest of the time:

  • re-read chapters 1-5 along with parts of chapters 6, 7 and 10 of K&B SCJP which Bert recommended
  • take all 6 mock exams from Enthuware JA +V7

How were the resources I tried

  1. K&B version 5 – Granted you’d buy version 6 at this point.  (or the OCA/OCP 7 version once it is out).  If you plan to take the OCP afterwards, I recommend going with this book to study.  If you just want to take the OCA, it is overkill as the information you need is mixed up with lots of harder information you don’t know.
  2. K&B SCJP 6 mock exam book – If you are planning to take the OCP afterwards and don’t mind the material being mixed together, this is a great resource.  If you want to get your OCA first without being exposed to the OCP information, it isn’t helpful though.  Also, some of the content is no longer on the exam so you have to ignore these parts.
  3. Enthuware JA +V7 – This was a great resource.  It was more difficult than the exam, but not overwhelmingly so.  The only topic that stood out as being on the mock and not needing to know was the ranges that primitive objects could hold.  A free 14 question trial is available so you can see what it is like before committing the $10.  Yes, you read that right.  You get 6 full length mock exams, analysis on your weak areas and the ability to retake questions by subject – all for ten bucks.  Even though there aren’t drag and drop questions, the mock exam still includes them because they are harder.  It also includes one or two fill in the blank questions.  (I found this to be practically impossible as a one character typo marks it wrong and then it is hard to compare to see why you were wrong.  But it isn’t frequent.)  The mock has been updated for Java 7 and the new objectives/difficulty.  I was highly satisfied with it. [My scores were 78%, 82%, 82%, 83%, 80% and 88%]
If you only have one resource, I would pick the Enthuware mock exams.

My impressions of the exam

  • Just like on the SCEA, I had a ton of time.  I had an hour left after taking all the questions and carefully reviewing them.  (I found one wrong answer on review.)
  • Unlike the SCEA, the questions are designed to be tricky/subtle.
  • It was similar to the Enthuware mocks in terms of facts/skills you had to know and format.  The Enthuware questions used some of the same variable names, class names and structures.  Kind of like the SCJP talks about horses.
  • I really like how the exam uses incredibly similar looking questions to ask different concepts.  Even within the same exam.  This prevents you from remembering much of use or memorizing much in advance.
  • A few questions had you flipping between the “exhibit” class and the question.  This was annoying because if you are looking for subtle details, it is a lot to remember between flips or *a lot* of flips.
  • While taking the mock exams, I found a technique that helped me limit stupid errors.  My score jumped 8-10% of the last mock I took (the only one using that technique) and then again on the actual exam.  On the mocks, I went too fast because the questions appeared easy.  On the final mock and real exam, I subvocalized as I read the code for *all* code questions.  This prevented my brain from going too fast and missing anything.
  • When you get your score report, it tells you which objectives you missed questions in.  Mine was “flow control” which tells me I made a stupid error in that space.

And finally, why you should visit a testing center in advance

Note: the testing center fixed the problems I had – see comment below this post for updates

I took the SCEA and Java Programmer part 2 exams at my local testing center which I am happy with. They provide you with pen/paper and a detached room from the office to take the exam.  The only distraction is if there is another person in the room with you and he/she stops and starts at a different time.  They take care to be quiet.

Then there was the center I was at today.  They gave me a *one sided* erasable markerboard to write on.  But that’s within their rights.  If you want paper, you should call and ask.  The exam was held in what looked like a closet.  A small table with two computers and poor ventilation.  It was hot!  And no soundproofing.  I heard everyone who walked into the office while I was there.  Which included an irate customer who had computer troubles and was dissatisfied with the speed at which they were fixing it (this went on for 10 minutes) and another potential customer who was inquiring about training. It was loud enough that I had to hold my ears to think.  Which doesn’t go well with using a mouse to select answers or trace code on paper.

I wanted to take the exam today because I was off work today.  And I figured minimizing the time between part 2 and part 1 would give me less time to get out of the habit of looking for details in exam questions.  It was the right decision.  But I wouldn’t recommend “Horizon Technical Consultants of Flushing” as a testing center for anyone.

“i want a career in java”; “java is the next cobol”

Over the past week, I’ve heard the following quotes “I want a career in Java” and “Java is the next Cobol.”  While these two statements don’t conflict with each other when taken literally, the connotations are quite clearly opposites.  Let’s take a look at themS

“I want a career in Java”

This is often asked in the context of a college student who doesn’t have any programming job yet.  So why Java specifically?  When I was in college, I wanted to be a developer.  Any language would have been fine.  It was where my path happened to take me that made me (currently) a Java developer.

Further, you don’t have a career in one programming language.  Things change too fast in technology for that to be the case.  So despite the fact that I’ve been a Java developer for the last ten years, it doesn’t imply that will be the language for my whole career.  Or maybe a career is a shorter term concept than that which I think of?

I think the context behind this statement is that Java jobs appear to be plentiful and pay well making them attractive to someone without any language experience.

“Java is the next Cobol”

A quick internet search says Java has been compare to Cobol since at least 2007.   Let’s see.  Cobol is a widespread language used in countless production applications.  It lasted decades.  It wasn’t cool, but it worked.  Not a bad place to be.

I think the context behind this statement is that Java isn’t cool anymore.  Or a “default” choice of language.  Which is fine.

Where we are

 These quotes show that we have people eager to learn Java and people predicting it’s demise at the same time.  Clearly the reality is somewhere in the middle.

Java is good for certain types of apps.  JVM languages are good for certain types of apps (especially when there is a desire to integrate with “legacy” Java code.)  As is .NET and Python and Ruby and …

Inovation is good.  That’s why we became techies!