Sorry, this entry is only available in Deutsch.

Sorry, this entry is only available in Deutsch.

Sorry, this entry is only available in Deutsch.

Sorry, this entry is only available in Deutsch.

Sorry, this entry is only available in Deutsch.

Here is the first article from Matthias Apitz <guru@UnixArea.de>

No article should start with “I”, (so first this sentence). I, Matthias, am glad to accept the invitation from my long-time colleague/partner Roland Dürre. From time to time I shall write about UNIX or other Open Source Projects. For more than 25 years I have worked with and for UNIX and believe that I have thereby learnt a bit. I am happy to pass on whatever I have not meanwhile forgotten. Enough of introduction; anybody who wants to know more about me, please see my home page.

First, something about large and small computers. A few days ago I bought my smallest computer yet, (excepting the programmable calculator TI 59 that I had as a student). It is a so-called sub-notebook, Asus eeePC 900: What is super about it is that is so small, but just big enough that one can really write on it and also read from the 9 inch (1064×600 pixel) display. It has no disk, only a 20 GByte SSD (Solid State Disk). That is storage as in a USB stick, but the operating system sees it as a normal ATA disc. 20 GByte is plenty. The operating system with everything needed for reading, writing and working takes 3 away, but then 17 remain. It weighs less than two pounds and is completely silent (unless one plays music or watches a film on it). And it comes not with Windows, but with a Linux-derivative from the firm Xandros, (more about that later). A version with XP is coming, but the SSD will then be only 12 GByte, because after all Microsoft must be paid (bad quality has its price) and the total price should not exceed 400 Euro. This is the smallest UNIX computer I have had so far. More about it later; but what about the largest?

Whoever looks at my home page will see that I come from East Germany (DDR). I went to University there, and later worked, researched and lectured on computers and programming languages at the Technical University in Leipzig. Germans of my age may well have heard of CoCom. Others can find it in Wikipedia. We were then not supposed to have any computers and certainly none with UNIX. That could not work, so the DDR built its own. Some were clones of IBM machines (IBM /360 and /370 became the DDR ESER 1055 and 1060) or of DEC (the PDP-11 was our SM4-20). Usually cloned operating systems of the American makers were used, but not always. The DDR universities had a research project to get various UNIX versions to run on this hardware. (Again contrary to CoCom rules, we had the sources). We managed this very well on the ESER 1055. It ran there in a virtual machine of the SVM as VMX (Virtual Machine uniX) and was used for teaching and research. The computer filled the whole computer room; the biggest disks were 29 and 100 MByte and looked like top-loading washing machines. I cannot remember the main store size (ferrite core store), but it was certainly less than 1 GByte. That was the biggest computer that I ever installed UNIX on, and yet its performance was much less than that of the eeePC, my smallest.

In those days, it was not easy with UNIX. It needed enthusiasts to beg for valuable computer time on the mainframe. Mostly we got this in the middle of the night. I shall skip other matters, such as the security aspect when visiting the holy machine room. There was also resistance as today from colleagues and chiefs who thought that an operating system could only come from IBM (today from Microsoft). But we prevailed.

Now naturally I work with a proper notebook, about 2 to 3 times as powerful as the nice little eeePC. OK, the display is 15 inch, not 27, but otherwise 2 to 3 is right. Neither XP nor Vista runs on it, nor will they ever! For many years, (with a short Linux interlude), I have used FreeBSD. The desktop with KDE or Gnome looks just like modern Linux, but still FreeBSD is for experts and admirers. Normally, as alternative to XP one would use a Linux version such as that from Novell, the (once German) SuSE Linux, or simply Ubuntu. Essentially they are all the same; they differ only in the installation and in outfitting. That holds for FreeBSD too. When it has been properly installed and configured, the difference from Linux on the desktop (KDE) is hardly visible.

I keep hearing four arguments against Linux/FreeBSD. All four are false!

Missing Hardware Support - that was earlier! Today almost all hardware is supported by Linux. When some exotic driver is missing, it usually soon appears. The cooperation between manufacturers and the Linux community (publication of specifications etc.) has improved; some manufacturers and service-providers themselves support Linux, e.g. Skype. The situation is now reversed, some hardware works with Linux, but not with Vista, (so Microsoft cannot take XP from the market).

Missing Support – false! If support via internet is not enough, one can get commercial PCs and laptops, with Linux pre-installed and with support. The internet support is unbeatable; a solution for every problem, or an answer to any question, comes almost immediately. And look how hard it is to get a solution to a Microsoft problem. I don’t think I need to give examples.

Compatibility – we need compatibility in our internal file formats and office products, and even more so compatibility with our customers. But that is really no argument against Linux. If the whole firm used Linux, we would certainly be internally compatible; certainly more compatible than at a firm where both MS Project 2003 and MS Project 2007 are running. Customer compatibility is no problem with the new Open Office products Version 3.0.

Nobody can really run it; nobody understands it – that was earlier too, when UNIX had only the command line. Modern desktops (KDE, Gnome) are more ergonomic than XP, simpler, faster and especially better documented. My wife comes from Columbia and is a computer amateur. She uses the computer mainly for surfing in internet (browser Firefox), email (hotmail.com with the browser), watching films (MPlayer plugin in Firefox), putting her photos in internet (Krusader, a sort of Norten-Commander where one drags and drops the files from the local file system to a remote ISP). Her notebook runs with FreeBSD and KDE. She knows that (because I once told her), but she doesn’t notice it. She has no problems and no viruses.

Occasionally I am forced to use XP, because some document is required to come from XP, e.g. an MS Project Plan, (that one could perfectly well do with GanttProject). For such cases I have a virtual machine with XP on my laptop. That gives the required compatibility.

Linux and FreeBSD have great advantages. They cost less (no license fees). They are more robust (no crashes). They are more secure (no viruses; any holes in the security get fixed at once). They are modern, open and ready for the future. Whole countries are changing to Linux. Munich city is changing thousands of workplaces to Linux. Perhaps I shall live to see my firm change completely to UNIX.

Why have I bought this little eeePC? There were two main reasons. The eeePC comes with a Xandros Linux, and everything else that one normally needs: Firefox, Skype, WLAN, OpenOffice, … and everything is nicely available via icons and tabs. Any child could operate it. I briefly scanned round it and saved a few files (e.g. the graphic-config of the X-servers) and then deleted everything! I was simply eager to manage to install FreeBSD on this midget without any CD/DVD for booting. Whoever wants to know how that is done can look at this link. Everything worked, except the on-board camera. The second reason was more normal, (and important for me). Almost all the books that I read privately are in Spanish, so I need the Royal Spanish Academy Dictionary when I am traveling. Now I have that too on my eeePC, which is no bigger or heavier than a book..

MAP

Matthias Appitz will contribute regularly to the IF-Blog about the chances that the Open Source world offers.

mehr »

Sorry, this entry is only available in Deutsch.

Sorry, this entry is only available in Deutsch.

Summary: “Entity” and “Object” are the keywords of this article. The differences between these concepts are well known, the catchword for that is “impedance mismatch“. This text, however, highlights their basic affinity and shows how this point of view may contribute to conceptual clarity and a reduction of modelling costs in IT-projects.

“An entity is an object that doesn’t know how to behave”. This is just one way to answer when asked to describe the connection between objects and entities. You may get other answers, a smirk for instance. Between object and entity there seems to be some sort of divide: “Entity” smells stale whereas “object” indicates modernity. Most current ideas and discussions in the domain of information technology use an object oriented approach and a vocabulary which differs in many aspects from the mindset associated with the notion of “entity”:

Table concerning „Impedance Mismatch“

The table names some of the differences while Charles Bachmann’s one-liner at the beginning stresses what both concepts have in common. The latter is what this text tries to explore. (Bachmann is known for one of the first modelling tools.)

A thought experiment: You are to build an application within a domain of your choice. Sketch a class diagram for that application, and then an entity-relationship-diagram. Or the other way round – start with your favourite approach. Then compare your classes with your entities.

My result: There is considerable agreement in an essential part of the diagrams. There are “boxes and lines”, there are “numbers” along the lines. Some of the object-oriented boxes carry the same headlines as their entity colleagues. In those places the two networks of lines fit very well together. So does much of the content of the boxes: the data elements. The classes, however, contain more entries than the entities: The latter lack the “methods” or operations and so are unable to express behaviour – that is what Charles Bachmann’s one-liner says.

Now let us have a look at those parts of the diagrams where there is no agreement.

Object but no entity. Consider the objects without corresponding entities. These are meant for processing data or interaction with the user. In the object oriented approach the window on the computer screen is an object, too. Entities, however, usually end up in the database and that is why such objects do not show up in the entity diagram. So we can say that the class diagram covers more ground than the entity-relationship diagram does.

Entity but no object: Conversely, you will find entities, but no corresponding object – at least at first glance. Looking closer you will find the missing data as parts of other objects. The object oriented approach allows nested data, whereas data in entities are flat. Nesting of data, however, comes at a price. We will return to this topic.

Objects are generalized entities: That is what we can conclude from what has been said so far. Small wonder: Entities were invented years earlier than objects. But the concept of “key” has been lost on the way: An object is an entity looking for its key …

Keys help clarify things: A key uses subject matter information to define what constitutes a duplicate and what does not. Whoever has engaged in defining keys with the future users of an application will be glad to have a coherent way of writing down the results. He will surely want to look them up afterwards. And he will be grateful for the effort to have taken place before much code has been written – especially if he is responsible for the budget.

Objects are numbered serially, so the above discussions will probably pop up later, perhaps too late.

Later in this text we will come back to this topic from a different angle. For the time being, we will look at practical reasons to wish for continuity between object and entity.

An extreme Example of “object equals entity”: Some time ago I had the opportunity to attend a presentation of a tool that generates code. You specify a graphical model of your application, plug it into the generator, which presents you with a working Java application and a restricted set of operations (create, retrieve, update, delete). The participants of the presentation were asked to vote for new features. The result: A database reverser. Its task is to extract the data structure from a live database and to convert it to part of the input for the generator. Not much more is needed for the generator to produce its Java-application. You can use the generated code as a basis to fill in the missing operations manually.

Whoever asks for such a database reverser must concede that for practical purposes it is quite irrelevant whether the box in the diagram is called entity or object.

Data modelling with object oriented tools: I work with programs that transfer models between modelling tools. Most of the class models on my desk are in fact data models conceived in an object oriented modelling tool. Why is that?

Object oriented tools are routinely used during conceptual work because - apart from organizing your data - you want to think through your processes. That done, the database gets its due, a task where the object oriented tools lack qualities. That is why after a while projects want to transfer their classes into a database design tool. The result of the transfer is useful as a basis for database design.

At this point the mental divide between object and entity gets in the way.

UML has no concept for “key”, (among others). The standard for object oriented modelling is called UML – Unified Modelling Language. It was preceded by a host of object oriented methods and wants to be their generalization. That accounts for the letter “U” in its name. Entities and related concepts have been treated somewhat harshly by UML, they simply don’t exist.

Additional expense because of constructs missing from UML. If a UML-tool is used for data modelling, existing UML-constructs have to be used in ways for which they were not intended. There is no “official” way to do this and so each class model that needs to be transferred into a database design tool looks different. This is obvious at the level of subject matter – but it is worse than that: The syntax is different. That is why more than just pushing the button is needed to transfer the model. The peculiarities of the model must be identified and a script must be written to neutralize them. Only then can the button be pushed.

Extending UML. There is some consolation: UML wisely refrains from completeness, see above, but it opts for extensibility as the superior concept. If constructs for a special purpose are missing, e.g. a key, then UML can be extended. Essentially the interested persons, projects or organizations themselves create the missing descriptive elements, and bundle them to form a so called “UML-profile”. After loading it into a modern UML-tool they can use the formerly missing constructs – e.g. the key of an entity. In organizations the profile is distributed together with the tool, which means that the user need not be aware of working with a profile instead of native UML.

Problem solved? Not quite. Each special purpose, each organization may create its own profile and does so. A project has to deal with various purposes and various organizations are engaged. Each occasion builds its own Babylonian Tower.

Database invisible? I can hear your objection. Who needs a database design tool to design his database? No need to bother with that. We have the data structures within the classes and we have tools to build the database on that basis.

It is in fact quite feasible to build a database application without ever laying hands on the database. This is an efficient way to build a single application. But in big organizations, you will very rarely find isolated applications.

If you have more than one application running on the same database things get a bit complicated. Nesting of data in objects is done to speed up operations, so different applications will need different ways of nesting. Having only one database, you will want a design that neutralizes the different data structures. That is what traditional database design does.

To sum up: Although continuity between entity and object is something natural and to be wished for, in practical situations there are problems. The reason? No idea. I consider it just an error that has not been corrected in time - just like the positions of letters on your standard keyboard.

Practical suggestions:

• When modelling persistent objects, try to find a key and check whether your users agree with your decision.
• If more than one OO-application is to run on the same database make sure that it is properly normalized.
• If you are modelling with an UML-tool and wish to design your own database, for instance in a multi-project-situation, try to find a UML-profile for data modelling that is already established in your organization and use it.
• Nudge projects working on “your” database in the direction of using the same modelling method as you do and be prepared to make compromises.

JJG