Home Evaluation Summary for programmers Product limitations Goals of Axisbase Quick start Installation Using the launchpad and opening databases Connecting to a sample database Using building blocks Planning Define the purpose Define the requirements Borrow existing work Determine the architecture Design the data model Design the process model Deploy and maintain the product
building blocksPerforming a mailmerge Bulk e-mailing
ProgrammingSingle-threaded progress indicator in c#
Database menu itemsImport XML Save Copy As Integrity Check Change Password
Database Properties windowOpening the database properties window Record types tab Display types tab Roles and Users tabs Sidebar tab Database ID/Links tab Counters tab
Building blocksBuilding blocks window Editing grids and cells Hyperlinks and nesting Data Subset window Data Outsource window List window Window window Report window Bulk Operation window Label Printer window Choosing a data source
Special topicsExpression syntax Browse records Storing building blocks within other building blocks Programming Using custom code in building blocks Using Axisbase as an embedded database Axis1.Util namespace reference Axis1.Data namespace reference (Fishnets) Axis1.Data namespace reference (other) Axis1.Forms namespace reference
Design the data model
A data model is a complete explanation of the database structure. Storing structured data is the whole point of a database, so this is the most important step to get right. Although the term "model" makes it sound preliminary, your data model becomes your real database structure.
Here are a few web tutorials on data modeling generally (not related to Axisbase). Further down on this page is a short introduction to data modeling, with information specific to Axisbase.
If this is new and confusing, don't worry. Getting these terms straight is the single most complicated thing about creating databases. So be patient and take the time to focus when you have no distractions.
If you don't have it all straight, this might help. Try to arrange the following words, listed alphabetically, into a suitable collection of record types, with properties.
Answer to mental exercise
There are two record types: "driver" and "truck".
A "driver" has the properties: "name" and "drivers license number".
A "truck" has the properties: "model", "owner", and "license plate number". The property "owner" is a reference to the record type "driver".
The words "Isuzu" and "Volvo" are not types or properties at all - they are example field values that would be appropriate for the "model" property.
Notice that the "owner" of the truck is shown as an arrow pointing to the whole driver, not one of the properies of the driver.
The available data types are named according to technical names in the Microsoft .NET platform. If you are a programmer, this makes things easy; if not, you get to learn something new today.
If you've used other databases, you might be wondering about nulls, which are a special value that many systems use to designate an unknown or blank value. Axisbase does not use nulls. That choice was made to prevent confusion between "null" and "empty", a distinction that easily leads to errors. The exceptions to this are that dates and references can be left blank.
Axisbase provides display types as a way to refine the meaning of the data types. Most display types are used with the string data type.
For example, if you define a property called "order status" you may want to restrict the values that can be entered to such things as "shipped", "hold", "backordered", and so on. Creating that restriction would help keep your orders organized. To do that,
There are several kinds of display types:
How do you create a data model?
One way to create a data model is to borrow a similar one and change it. [Some examples will be posted here.]
There are lots of professional tools for complex data modeling, but you can do it in a word processor just as well. For a very simple project you could skip typing it out and just enter it directly into Axisbase, but having it in a word processor has some advantages: It helps you organize your thoughts, and then after the project is live, you can use it for ongoing documentation and reference.
If you don't have the background and you are utterly bewildered at this point, but you still want to do the project yourself, consider outsourcing the work of developing the data model. As stated, it is the most critical thing to get right. If you have a professionally design data model, you are more likely to successfully carry the project forward from there than if you have mistakes in the data model.
Example date model
This data model stores responses to survey questions.
Note that the meaning of each property is explained in the notes column, unless the property name makes it obvious. Any use of display types is noted, as well as any restrictions on numeric range and the allowed length of string fields.
Record Type "surveyor" - a person who asks the survey questions. There are only a few of these records.
Record Type "session" - a record of a survey session and the person who answers a survey. (If the same person participates twice, there would be two records here for the person)
Record Type "answer" - each answer in a survey session becomes one "answer" record.
This model represents the result of a set of choices about how you want to to business. For example, it indicates that if the same person takes a survey twice, the surveyor would enter a new session record the second time. Depending on the nature of the business, it might have been a better choice to add a new level - a record type "respondent" with properties firstname, lastname, dob, and address. The "session" type would still contain the properties surveyor and venue, and would also contain a new property, the reference to the respondent record. That would allow tracking sessions by respondent.
Another important choice this data model makes is that the company does not store the survey questions in the database at all. An alternate design would be to add record types "survey" and "question" (continaing a reference to the survey); and changing the "answer" type to contain a reference to the question being answered.
It all depends on how you want to do business.
Included record types
Axisbase allows you to re-use record types within other record types. A very common use of this is for mailing addresses. If you have record types for clients and vendors and employees separately, and they all have mailing addresses, you can save some work by defining the address type once and use it in all three places.
Example, you define "address" with the properties line1, line2, city, state, and zip. (The example is for US addresses.)
Properties for the "employee" type are: name, address, and department. The "address" is not a reference to an address record; it is rather an inclusion of all the address properties within the employee record type.
Axisbase shows this as "one address", as opposed to "reference to address".
When you use included types, and you change the included type, Axisbase makes the change consistently throughout all types. For example, if you change the "address" type to include a country property, then clients, vendors, and employees will all be changed to include that new property.
Enforcing business rules
Axisbase knows how to enforce some the rules that you type into your data model document. "Enforcing" rules means preventing users from entering records that don't adhere to the rules. It doesn't know how to enforce all rules, but there are ways to write code to enforce all the rules.
Going the extra mile up front to make sure that rules are enforced usually saves work later on. (A stitch in time saves nine.) For example, if you have a large database and discover that hundreds of customer records have blank names, you will probably wish that you had prevented those errors from being entered in the first place.
The term business rule usually refers to the meaning or accuracy of the data, such as the rule that an email address must contain the @ character. A data integrity rule usually refers to the structure of the database, such as the rule that a line item on a sale must refer to an existing product. Here, we will not distinguish between these.
Here is a list of different kinds of rules, and how you can enforce them.
Under the hood
The technical information in this section clarifies how Axisbase does some things, which you may find useful when working out a data model. You don't need to know this information.