Ever since businesses started using computers, the idea of developing applications without programming has been the Holy Grail of business application development. Businesses don't want to employ costly programmers who don't produce any of the company's products; they want their users to produce their own applications. The main problem with this great idea is that applications must be programmed, and users don't know how to do that.
Approximately 15 years ago, a short-lived British company (the name of which escapes me now) marketed an automatic application generator named "The Last One." The company gave it that name because it claimed the program was the last you would ever have to buy. If you had The Last One, it would create any applications you needed from then on. Alas, The Last One is no longer with us. It was not the last one. In fact, several major DBMS vendors have produced application generators since then. Unfortunately, these tools have generally exhibited rather limited capability, and they are applicable to only the simplest of problems.
Now Wall Data has announced the availability of Salsa for the Desktop, a business application builder for personal and small workgroup applications. Is this finally "The One" for which businesses have been waiting? Will it truly allow non-programmers to build useful applications, or should we look for Another?
Salsa is different from all previous products that attempted to deliver code-free application development, and the difference is fundamental. At Salsa's core is the Semantic Object Model (SOM), which Wall Data's chief technologist for Salsa products, database veteran Dr. David Kroenke, developed. [Editor's note: An upcoming issue of DBMS will compare SOM, traditional entity relationship modeling, and Object Role Modeling as used in InfoModeler by Asymetrix Corp. Kroenke was interviewed in DBMS, September 1994, page 60.] The SOM was developed over the last five years and represents a database the way its users conceptualize it, rather than in terms of tables, links, keys, and other arcane items known only to professional database developers.
Salsa builds a database model from a user-entered description and then creates a corresponding relational database schema. Users enter the description by dropping template objects onto a work surface and then customizing their properties. For most jobs, coding is not necessary. For those cases in which a little code is needed, Salsa Basic is available. In keeping with the visual nature of the Salsa user interface, Salsa Basic is similar to Microsoft's Visual Basic. Although Salsa's designers provide Salsa Basic, they hope that you will never need to use it.
In any business enterprise, database tasks of varying magnitudes are needed. These range from enterprisewide, mission-critical applications to small personal database applications that help a worker operate a little more efficiently. Salsa attacks the problems at the low end of the application spectrum. It is targeted at applications that address the modest needs of single individuals or small workgroups. Users who are familiar with the task to be automated but have no concept of database theory or programming can produce functional and reliable applications with Salsa. Furthermore, they will probably be able to do it faster than a trained systems analyst using traditional tools could do it.
A major advantage of Salsa is that many useful applications can be developed that would otherwise never see the light of day. Few companies have enough MIS staff to fulfill all end user requests promptly. That means that the best analysts will be working on mission-critical applications most of the time. Small applications that would benefit only one employee or a small group of employees might never get written. With Salsa, users don't have to wait for the IT department's work to slow down; they can develop their own applications. Furthermore, some may argue that the application will be better than one developed by a professional, because it will do exactly what the user wants it to do, rather than what the professional developer thinks the user wants it to do, or what the developer thinks it should do.
To create a Salsa database, you must consider which objects are important. Any object that you want to keep track of should be an object in the model. Objects are specified by profiles. A profile may describe a single property of the object or a group of its properties. For example, the Phone property could be a group that includes Country Code, Area Code, and Local Number. The model reflects the way the user thinks, rather than some ideal of a normalized data structure.
According to Wall Data, the essential motivation behind Salsa is to have humans do what humans do best and computers do what computers do best. That is, humans are best at modeling a problem in terms that correspond closely with their own mental model of the problem. Computers are best at repetitive, algorithmic tasks, such as turning a semantic model into a properly structured, fully normalized database. Salsa provides the visual tools to create an SOM that matches your mental concept of the problem domain. It then takes over and converts that model into a relational database in Domain Key Normal Form (DK/NF). Salsa uses your objects as a starting point, then generates whatever additional tables, keys, and constraints are needed to put the system into DK/NF. It has been conclusively shown by R. Fagin that a database in DK/NF will not be subject to any modification anomalies.
Once you have entered the model and Salsa has created a database, you can use Salsa's forms creation tool to build forms for accessing the data contained in the semantic objects, and the report creation tool to create printed reports. You never have to know in which tables the data is actually stored -- or, in fact, that things such as tables are involved. You interact only with the semantic objects that you created.
When you have defined the relevant forms, reports, and application menus, you can give Salsa the go-ahead to create the application by making a menu selection. It will do so, producing an application with the familiar Windows look and feel. You should try out all the application's functions. If any don't turn out exactly as you planned, you should go back and make appropriate modifications. When the application is in final form, you can create a runtime version. You cannot modify this version, so you should keep the development version, just in case you need to modify the application in the future.
Installing Salsa is simple; it is a standard Windows Setup operation. After installing Salsa, you can take a tour of all of its major areas on a "virtual tour bus." If you already have data stored on one of the major personal DBMS file formats, you can import the data into Salsa, generate a schema, and then create an application to access the data.
All of Salsa's documentation is online; there is no printed manual. Users who are accustomed to learning a product by reading its manual will experience a vague sense of uneasiness until they reprogram themselves to consult the online help whenever they have a question. An important aspect of the online documentation is the Learning Studio. This includes the virtual tour bus as well as an overview of the Salsa philosophy, fundamental Salsa concepts, and answers to commonly asked questions. The Learning Studio also incorporates the Interviewer, which walks you through the creation of a database and its associated application. You can use the Interviewer to build applications until you feel comfortable building them yourself.
One limitation of the current version of Salsa is the inability of Salsa applications to interact with data in ODBC-compliant databases. If you have a database in some foreign format, you must import it into Salsa format before you can access it with a Salsa application. This is a major deficiency for anyone who wants to create Salsa applications to work against existing databases. Another limitation (which Wall Data intentionally imposed on the product) is the fact that the SQL code that Salsa generates is not available for you to modify or even inspect. To safeguard the integrity of the database schema, Salsa doesn't let you get anywhere near it. It also means you cannot inspect the SQL code to be sure it is correct. This overzealousness in protecting the SQL is probably misguided. Databases created by end users often don't do exactly what they were intended to do. At this point the problem is usually dumped in the lap of the MIS support people. These people want and have a legitimate need to see the SQL, and they should be able to do this. Perhaps Wall Data could implement some kind of password protection that would allow authorized personnel to access the SQL while hiding it from the user/developer.
Salsa is an ambitious product. It is a serious attempt to put nontrivial database application development into the hands of the users of those applications. As such, it is unlike any other development product on the market today. It communicates with users and developers in terms that they understand. It does not require a knowledge of database theory in order to produce a reliable structure that is free of modification anomalies. If a Salsa application that starts out serving a small workgroup evolves into something larger, Salsa might have difficulty scaling it up. Nevertheless, in the area of relatively simple low-end applications, Salsa should see widespread use.