Less and Less Visual

  • Comments posted to this topic are about the item Less and Less Visual

    Best wishes,
    Phil Factor

  • Phil Factor. Great name for a dba.

  • I dont actually believe that many understand ERDs. Would like to see a survey on what people do know, and the extent.

    Last few companies I have worked at none of the DBAs or developers understood what a ERD was. Blank expressions have been the norm. Suggest it as a method of resolving a dispute on the suggested relationships of the schema and they have often not understood or refused it as the "code knowns"; yeah then why the discussion in the first place?

    My issue with the diagramming tools that MS provide is that they have such basic notation.

  • Visio is my favourite tool for documentation and design (and the one available when you work in a restricted Microsoft shop!).

    I reverse engineer my databases into Visio Premium to give visual documentation easily.

    I started with Visio just at the point where Microsoft bought it and it was a better product in those days, because you could both reverse engineer from SQL Server AND forward engineer your design, but the latter option was removed as Microsoft "developed" the product.

  • @Yet Another DBA

    For years, I did all my work in ErWin, which is a good ERD tool, and I very seldom used SQL code for designing databases. Mind you, I was engaged in doing high-level design at the time and the mapping of corporate data, and only did the first cut of the physical model from the ERD, but it has given me a great respect for the power of the ERD. I really would recommend diagramming the database model for as long as possible in the course of development. You can always use the diagrams in the subsequent documentation.

    Best wishes,
    Phil Factor

  • P Jones (6/26/2014)


    Visio is my favourite tool for documentation and design (and the one available when you work in a restricted Microsoft shop!).

    I reverse engineer my databases into Visio Premium to give visual documentation easily.

    I started with Visio just at the point where Microsoft bought it and it was a better product in those days, because you could both reverse engineer from SQL Server AND forward engineer your design, but the latter option was removed as Microsoft "developed" the product.

    +1

    I used Visio from time to time, but they took out the best features in later editions.

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • There does seem to be a loss in the community (generalising here so many of you will be exceptions!!!) of using visual tools for anything but documentation. I agree that scripting is, or at least can be, very powerful and shouldn't be overlooked but there are proven psychological reasons why visual representation is a better form of communication over text. Yes, you can argue that text is less likely to be prone to misinterpretation and ambiguity but I do think that we have lost some tools and that is rarely a good thing. In the 80s and 90s there was a lot of effort to bring the power of visual representation to the IT professionals. Sadly, this appears to be discarded now.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Does a whiteboard and a smartphone count as a tool? I agree that some more visual tools would help us be more effective. People who have a great mind for the abstract can "see" the data and relationships more easily than others, especially with experience. Graphical tools allow this meta data to be stored and shared so it doesn't have to only take up space in your working memory and who doesn't want to have more memory available for processing?

  • Several have commented that the current trend seems to be toward text with the feeling that text is more accurate. I think that the opposite is true, text has become much less accurate in every dimension of communication and is no more accurate in database descriptions. Much has been written about the rise of the "texting" vocabulary in all aspects of communications and it coincides with the general degradation of the written word in society. With mounting evidence that text is less and less precise how can it be a more precise representation of a concept than a visual representation that is prima facie accurate and not open to the interpretation that text is? I have been waiting years for good and affordable graphical tools to use in engineering and reverse engineering databases and applications as both time saving devices and as higher level abstract representations of the code and just when I thought they were arriving they seem to be going away. This is a sorry state of affairs for current work and advancement of the discipline.:(

  • charles.green (6/26/2014)


    Several have commented that the current trend seems to be toward text with the feeling that text is more accurate. I think that the opposite is true, text has become much less accurate in every dimension of communication and is no more accurate in database descriptions. Much has been written about the rise of the "texting" vocabulary in all aspects of communications and it coincides with the general degradation of the written word in society. With mounting evidence that text is less and less precise how can it be a more precise representation of a concept than a visual representation that is prima facie accurate and not open to the interpretation that text is? I have been waiting years for good and affordable graphical tools to use in engineering and reverse engineering databases and applications as both time saving devices and as higher level abstract representations of the code and just when I thought they were arriving they seem to be going away. This is a sorry state of affairs for current work and advancement of the discipline.:(

    I agree with most of what Charles says here but, at least for my part, executable text is verifiable whereas a non-executable graphical representation is not. A document was certainly not what I had in mind.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • CodeFirst has a few nice features...there's the power tools and multiple diagrams per model features:

    http://www.entityframeworktutorial.net/EntityFramework5/multiple-diagrams-in-entity-framework5.aspx

  • Well Gary I have to agree with you there. However it is at that point where applications that can turn a diagram into usable code come in handy. Granted generated code is not always the best code, it provides a framework for the work at hand. I have found it useful to be able to go back and forth between a graphical representation for the conceptual view and go to the code (text) to make the fine tuning. Without the ability to 'See' the objects in context I find myself slipping back into procedural (spaghetti) code rather than object-oriented code. I guess that shows my age and that I started out as a programmer but not of databases where I find myself now.

  • Gary Varga (6/26/2014)


    I agree with most of what Charles says here but, at least for my part, executable text is verifiable whereas a non-executable graphical representation is not. A document was certainly not what I had in mind.

    I am ultimately more comfortable with text as the final product (though tools like Query Editor are great ways to check your work or analyze queries). Somehow I have never been completely comfortable with the graphic SSIS envirionment compared to text based techniques like SQL or Powershell.

    ...

    -- FORTRAN manual for Xerox Computers --

  • A couple thoughts came to me as I read the editorial:

    1. In at least one case, when designing views, I think creating using tsql is so much easier than using that clunky table builder. My eyes spazz out when I accidentally hit the Design option on a view and see all that info stacked up on the screen. I quickly X it out and script as modify to a new query window, where I can easily read the definition of the view.

    2. I've only been a DBA for 2 years, so not very experienced yet, but I have no experience using diagrams in a database. I've learned relations by exploring databases and troubleshooting issues, but I've never used diagrams. Maybe they would be easier to use, maybe not, but I haven't felt disadvantaged because the companies I've worked for don't use them.


    [font="Tahoma"]Personal blog relating fishing to database administration:[/font]

    [font="Comic Sans MS"]https://davegugg.wordpress.com[/url]/[/font]

  • Back in the mid 90's, I was lucky enough to serve FedEx as subject matter expert and project lead for the first methodology-driven application to be delivered that was based on the recently completed information strategy plan for the Air Operations Division we spent nearly two years developing. As a small group of about 10, those of us who developed the plan had spent the first several months evaluating and selecting first a methodology, and second a documentation and application delivery environment to support it. We selected James Martin's Information Engineering methodology, and then the IEF toolset from Texas Instruments, precisely because it was entirely graphical in nature, and generated all the code required to implement the documented business rules and entity relationships directly from the diagrams. It went far beyond what we used to call 4GL Generators to fully integrated CASE, in that the resultant code included all the DDL, stored procedures, messaging, and client code targeted to practically any database, O/S, or browser (back when everyone used Netscape :)). So, to the point of the discussion, we have definitely digressed from what was state-of-the-art with graphical design and development tools used to be, to today.

    One of the most valuable components of the IEF toolset was its powerful ERD tool. The purpose of the tool was not just for the programmers. Programmers tend to be self-interested when it comes to tools. Before anyone gets defensive, let me say I have been a programmer since the 70's, and have worked with, hired, and managed hundreds of them over the years, so I get to have an opinion. The greatest value in the ERD (and DFD, for that matter) is as a tool to gain consensus with the user about what an application is to do. The number one reason I've seen application development efforts fail is because the folks doing the programming just thought they understood what the customer wanted, and then included a healthy dose of what they "really need", and so delivered a glove that did not fit the hand as expected. Through experience, I assert that ERD and DFD are the most effective tools available, even yet today, with which to communicate analysis and design constraints back to a customer, before any coding or design is started. If you do not have an agreement on terminology, the entities involved and their relationships, and what business rules are about to be implemented, you are really wasting your time and the customer's to go any farther. ERD and DFD pictures are easy enough for any business unit manager to understand. I have taught them untold times in my career, sometimes to audiences over a hundred. I always start my presentations with a quick review of how to read the diagram, which takes 5 minutes.

    The beauty of the IEF was the ability to drive the documentation to such a detailed level that the code came from it instead of vice-versa. Another common failure of applications is lack of documentation and eventual death through the inability to maintain and extend them as a result. With the IE methodology, the documentation is done first. What a concept. You actually get to know what the finished product looks like before starting. I suspect most programmers who would think that diagrams get in the way and have no value, would also allow a home builder to just start nailing lumber together to build their house without any plans or diagrams. Just trust me 🙂

    The ugly news is, IEF is no longer available. I understand it has evolved into a product call GEN from Computer Associates, but I have no idea what it costs or what it offers. The worse news is, at FedEx we spent several million dollars over the course of three years learning the methodology and the toolset, developing the underlying information repository, ERD, AHD, RAW Matrices, etc. required to get to the generation level, and then applying them to the first application. The application was great success, and the architecture was then in place to quickly develop additional applications, but the front-end cost was high.

    Today, I use the same flaccid diagramming tools that are already mentioned in this blog, like Visio, to develop my ERD and DFD for new work. I have a tool that was given to me by Texas Instruments when the IEF training was completed, called Business Design Facility, that I use if I'm the only one who will be working on the diagrams because I can't share it. I would personally love to find another tool like IEF that I could afford to own.

    As a last word to programmers who dislike diagrams and favor the "makes me look really smart" approach of screens of code, please reconsider. The diagrams and CASE are not attempts to make you redundant, any more than the machine gun made foot soldiers redundant. They are just extremely effective ways to improve your efficiency and effectiveness by providing an iron clad way to understand the problem before developing the solution and removing ambiguity about whether the solution is correct or complete.

Viewing 15 posts - 1 through 15 (of 24 total)

You must be logged in to reply to this topic. Login to reply