Before you start setting up your own database projects and entering data for them, you should now about some basic concepts MUIbase is built on.
A MUIbase project consists of all relevant information you need for managing your data. This includes the project's user interface, the project's data you entered and the programs you wrote for the project.
A project can be loaded from, saved to, and deleted from disk. Any change you make to a project is only done in memory. At any time you can go back to the state of the last saved project by reloading it.
MUIbase is able to handle multiple projects at a time. Therefore it is not necessary to start MUIbase twice just to load another project.
MUIbase manages data in tables. A table is organized in rows and columns, where rows are called records and columns are called attributes.
See the following table for an example on how to structure a set of addresses in a table.
Name | Street | City
------------------|---------------------|------------------------
Steffen Gutmann | Wiesentalstr. 30 | 73312 Geislingen/Eybach
Charles Saltzman | University of Iowa | Iowa City 52242
Nicola M�ller | 21W. 59th Street | Westmont, Illinois 60559
There exists a special table kind which can hold exactly one record. A table of this kind is sometimes useful for controlling the database project, e.g. you can put buttons into this table for executing various actions, or a read-only attribute for displaying project related information. For an example suppose you have an account database where you store all your income and expense. An exactly-one table now could have a read-only attribute of type real for displaying the total balance.
Each table has two record pointers, a pointer to the record that is currently displayed in the user interface (called gui record pointer) and a pointer to the record that is the current one while executing a MUIbase program (called program record pointer).
You can define any number of tables for a MUIbase project. (Note: in the unregistered MUIbase version there is a limitation of 5 tables per project).
Tables can be added to, renamed, and deleted from a project.
A record is one row of a table. It holds all information about one set, e.g. in a table that manages addresses, one record holds one address.
Each record has a record number that reflects the record's position in the table. This number may change when you add or delete records.
For each table a record called initial record exists that holds the default values for initializing new records. The initial record always has a record number of 0.
Records can be added to, changed, and deleted from a table.
There is no upper limit on the total number of records for a table.
The records are not necessary held in memory but are loaded from
and stored to disk when needed.
Ok, there are two upper limits for the total number of records of one table.
One comes from the fact that the record number must fit into
a long value, which limits the total number of records to 4294967295.
Another limitation is that for each record a small record is
kept in memory.
These limitations should make MUIbase still be usable for record numbers
of 10,000 and more.
An attribute defines one column of a table. It specifies the type and appearance of the corresponding column.
Attributes can be added to, renamed, and deleted from a table. There is no upper limit on the number of attributes per table. (Note: in the unregistered MUIbase version there is a limitation of 10 attributes per table).
For each attribute you have to specify a type that restricts the contents of this attribute. See the next section for a list of available attribute types.
Attributes can be of type string, integer, real, bool, choice, date, time, memo, reference, virtual, or button. The types are described in more detail below.
Some of the attribute types support a special value called NIL. This special value has the meaning of an undefined value, e.g. for a type of date it means an unknown date. The NIL value is similar to the NULL value of other database systems.
Please note that once you have set the type of an attribute, you cannot change it later.
String attributes can store any single line of text. Strings are the most often used attribute type in a database project. For example an address database will store the name, street, and city of a person each in its own string attribute.
For a string attribute you have to specify the maximum number of characters allowed in the string. This number does not directly affect the amount of memory or disk space that is used by this attribute because only the actual string contents are stored (other databases have called this feature compressed strings). If necessary the number can be changed after you have installed a string attribute.
String attributes can also be used to store font- and filenames. For filenames external viewers can be launched to display the file contents. Furthermore an in-line image class allows displaying the image of a file.
String attributes do not support the NIL value.
Integer attributes store integral values in the range of -2147483648 to 2147483647. They are mostly used for storing quantities of any kind, e.g. the number of children of a person, or the number of song titles on a CD.
Integer attributes support the NIL value representing an undefined integer value.
Real attributes store floating point values in the range of -3.59e308 to +3.59e308. They are used for storing numbers of any kind, e.g. the amounts of money in an income/expense project.
For each real attribute you can specify the number of decimal places used for displaying the real value, though internally always the full precision is stored.
Real attributes support the NIL value representing an undefined real value.
Bool attributes store one bit of information. They are used for storing yes/no or true/false values, e.g. in a project managing invoices a bool attribute could store the `has paid?' information.
Bool attributes use TRUE and NIL as bool values. NIL in this case stands for a value of FALSE.
Choice attributes store one item out of an enumeration of items. For example, in an address project a choice attribute can be used for storing the state, where state is one out of `USA', `Canada', `Germany', or `others'.
A choice attribute does not store the whole item string but the item number (index) in a record. The number of items and the items itself can be modified after the attribute has been created. However when making changes to a choice attribute, values in existing records are not changed to reflect the new situation.
Choice attributes do not support the NIL value.
Date attributes store ... ehm ... dates. For example, a date attribute can be used for storing birthdays.
The format for entering and displaying date values can be one of `DD.MM.YYYY', `MM/DD/YYYY', or `YYYY-MM-DD', where `DD', `MM' and `YYYY' are standing for two and four digit values representing the day, month and year of the date respectively.
Date attributes support the NIL value representing an undefined date.
Time attributes store times or periods of time. For example, a time attribute can be used for storing the durations of music titles on a CD.
The format for entering and displaying time values is fixed to `HH:MM:SS' where `HH' is a two digit value in the range of 0 to 23 representing the hours, `MM' a two digit value in the range of 0 to 59 representing the minutes, and `SS' a two digit value in the range of 0 to 59 representing the seconds.
Time attributes support the NIL value representing an undefined time.
Memo attributes store multi-line text of any size. Text size is handled dynamically which means that memory is only allocated for the actual text size. In a project managing movies for example, a memo attribute can be used to store summaries of the movies.
Memo attributes do not support the NIL value.
Reference attributes are a special type of attributes, normally not found in other database systems. Reference attributes store a pointer to another record. The referenced record may reside in the same or in any other table than the reference attribute belongs to.
For example in a pedigree project two reference attributes can be used for storing pointers to the father and mother record. Or in a project managing CDs and music titles, a reference attribute in the table holding the music titles can be used to point to the records of the corresponding CDs.
For displaying a reference attribute, any attributes of the referenced record can be specified. Entering a reference attribute can be done by selecting a record from a list of records.
Reference attributes support the NIL value. Here a value of NIL stands for a pointer to the initial record of the referenced table.
Virtual attributes are a special type of attributes that do not store any information in the database itself, but compute them on the fly when needed.
For example, in a project managing invoices where a real attribute holds the amounts of money excluding tax, a virtual attribute can be used to "store" the amounts of money with tax. Every time the value of the virtual attribute is needed, e.g. for displaying it, it is computed from the corresponding value without tax.
For displaying virtual attributes three kinds exists: bool, string and list. These three kinds allow showing the value of the virtual attribute as a TRUE/FALSE value, as a single line of text including numbers, dates, and times, or as a list of several single lines, e.g. for listing all music titles of a CD.
Virtual attributes support the NIL value standing for FALSE (bool kind), undefined (string kind), or empty (list kind).
Actually, buttons are not a real attribute type as they cannot store or display any information. Buttons are just used for triggering MUIbase programs.
The reason to keep them as an attribute type is because as an attribute buttons can be accessed by their attribute name. This allows to use the name of a button in a MUIbase program, e.g. to disable or enable the button. Another reason is that buttons have similar properties as attributes, e.g. trigger functions.
The following table summarizes all available attributes types:
Type Description Nil allowed?
String For strings of lengths 1..999. No
A string can also be used for storing
filenames, font-names or one-string-
out-of-n-strings. For filenames you
can add a field where the contents
of the file are displayed as an image.
Integer For storing integer values. Yes
Real For floating point numbers. Yes
Bool TRUE or NIL. Yes (NIL = FALSE)
Choice One number out of n numbers. Numbers No
are represented by label strings.
Date For storing a date value (1.1.0000 - Yes
31.12.9999).
Time For storing time values (00:00:00 - Yes
23:59:59)
Memo Multi-line text of unlimited length. No
Reference For storing a reference to a record Yes (NIL means
of another table. initial record)
Virtual For displaying results from a MUIbase Yes
program.
Button For triggering a program function No (N/A)
Each attribute type needs a certain amount of memory for storing one value in a record. All types except virtual and button have in common that they need a 2 bytes header holding internal information. Additionally, type dependent space is needed for storing the actual value. The following table lists how much memory including a possible 2 byte header one value of the given type needs in memory and on disk.
Type Memory space Disk space String 2 + 4 + string-length + 1 2 + string-length + 1 Integer 2 + 4 2 + 4 Real 2 + 8 2 + 8 Bool 2 + 0 2 + 0 Choice 2 + 2 2 + 2 Date 2 + 4 2 + 4 Time 2 + 4 2 + 4 Memo 2 + 4 + memo-length + 1 2 + memo-length + 1 Reference 2 + 4 2 + 4 Virtual 0 0 Buttons 0 0
Here string-length stands for the length of the string to be stored and memo-length for the text size of the memo to be stored.
Up to now you know how to organize your information into tables with records and attributes. But you may also want to setup relationships between tables.
For example if you want to collect CDs in a database project you would have two tables, one for the CDs them-self and one for the music titles of the CDs. Of course you could also have all music titles within the CD table but then you would have a fixed number of music titles for each CD.
So having these two tables, you now need a link for each music title to the CD containing this title. This is called a relationship between the two tables. Normally you use a reference attribute for setting up such a relationship.
By installing a reference attribute into a table you automatically have a relationship between the table the attribute resides in and the table it refers to.
One to one relationships are very simple relationships where for each record you have one or zero partners in another or in the same table.
For example in a database project that manages your favorite movie actors you could setup a reference attribute called `married with' that shows the person the actor is married with. An actor that is currently not married does have a NIL value for this reference field.
Of course, no one prevents the user to set the `married with' references of several actors all to the same person. However by programming MUIbase it is possible to detect such cases and handle accordingly.
One to many relationships are useful for connecting a set of records to one record in another or the same table.
For example in a project managing your bank accounts you could have one table for all bank accounts and one table for all transactions. Now you surely want to know which transaction belongs to which account so you setup a reference attribute in the transaction table referring to the account table.
One to many relationships are the most often used ones. You can use them for managing any hierarchical-like structures, e.g. CDs with music titles, bank accounts with transactions, family trees, etc.
One to many relationships are also the basis for realizing many to many relationships as described in the next section.
Many to many relationships are used when you want a set of records to refer to another set of records.
For example in a project that manages movies and actors you would have two tables, one for the movies and the other one for the actors. Now for each movie you want to know the actors that took part in the movie. So you might think to setup a reference attribute in the actor table that refers to the movie table. But when doing this you could only have one movie referenced for each actor because there is only one reference field in the actor table. So what you need is an unlimited number of references from the actor table to the movie table.
This is done by adding a new table that just has two reference attributes, one pointing to the actor table and the other to the movie table. Now you can enter the relationships by adding new records to this table. For each movie-actor constellation you add a new record and specify the movie and actor by setting the corresponding reference fields.
If you want to know in which movies an actor took part then you only have to search for all records in the new table that refer to the actor in question and look at the movie records the found records refer to. Such a search can be done automatically by MUIbase and the result can be displayed in a list-view.
The following tables show an example of how to connect a set of actors to a set of movies.
Title Country
----------------------------
m1: Batman USA
m2: Batman Returns USA
m3: Speechless USA
m4: Tequila Sunrise USA
m5: Mad Max Australia
m6: Braveheart USA
Name
-------------------
a1: Michael Keaton
a2: Jack Nicholson
a3: Kim Basinger
a4: Danny DeVito
a5: Michelle Pfeiffer
a6: Geena Davis
a7: Christopher Reeve
a8: Mel Gibson
a9: Kurt Russell
a10: Sophie Marceau
a11: Patrick McGoohan
a12: Catherine McCormack
a13: Christopher Walken
MovieRef ActorRef
------------------
m1 a1
m1 a2
m1 a3
m2 a1
m2 a4
m2 a5
m2 a13
m3 a1
m3 a6
m3 a7
m4 a8
m4 a5
m4 a9
m5 a8
m6 a8
m6 a10
m6 a11
From these tables you can find out for example that Mel Gibson took part in the movies Tequila Sunrise, Mad Max, and Braveheart, or that in movie Batman the actors Michael Keaton, Jack Nicholson, and Kim Basinger took part.
MUIbase uses a graphical user interface (gui) organized in a hierarchical way for displaying record contents and for letting the user enter new data. Each project owns its own root window in which further gui elements (including sub windows) can be placed. The gui elements are also called display objects.
A table is displayed in an own gui element called mask. A mask can display only one record at a time. Its layout and the attributes included in the mask are customizable by the user.
The following sections describe MUIbase's gui elements for designing a project's layout.
Windows can be used to spread information of a project across several independent areas.
Each project automatically has its own root window. If needed, e.g. if the space of the root window exceeds, additional sub windows can be created. Sub windows can also have further sub windows.
For each sub window a window button is placed into the parent window allowing to open and close the sub window. The window button looks like a normal text button but has a small window icon showing the open/close state of the corresponding sub window.
Root windows do not have a parent window and therefore have no window button. Closing a root window means closing the whole project.
A window can have any other gui elements (except panels) as children. If no child has been added to a window then an `empty display' image (see section Empty display image) is shown.
A mask is used to display the contents of a table. Only one record of the table can be shown at a time.
The mask may include a panel (see next section) for controlling the table. Other gui elements like attribute or text objects can be placed into a mask to show the record contents.
Masks cannot be placed inside other masks as this would lead to a hierarchy of masks and therefore to a hierarchy of tables which is not supported in MUIbase. If you want to setup a hierarchy of tables, use an 1:n relationship between two tables.
A panel is a small rectangular area placed at the top edge of a mask. A panel can display a title, e.g. the name of the corresponding table, a pair of numbers showing the record number of the current record and the total number of records, and several buttons for controlling the table, e.g. for displaying the next or previous record.
Only one panel can be defined for a mask. If you setup a panel for a mask then an additional border is drawn around the mask, otherwise no border is drawn.
Attribute objects are used to display the contents of one item of a record.
Depending on the type of the attribute the gui element is either a string gadget (types string, integer, real, date and time), a check-mark gadget (type bool), a cycle gadget or a set of radio buttons (type choice), an editor gadget (type memo), a pop-up list-view (type reference), a text, check-mark, or list-view gadget (type virtual) or a text or image button (type button). In some cases the gui element may also be a simple text gadget if the attribute object is set to read-only.
Text objects are used for describing the various field elements of a record mask or just to display some static text like copyright information somewhere in a window.
Images can be displayed anywhere in a window. An image can be an internal MUI graphic, a simple color field, or a pictures from an external file. The image size can be set to resize-able or fixed.
The image is static. If you would like to store images in a table you should use a string attribute (see section String attributes).
Please note that images are not available in the unregistered version of MUIbase.
Space objects are used to insert space in the layout of a window or a table mask. A space object can have a vertical (or horizontal) bar for delimiting other gui elements.
Gui elements can be grouped into horizontal or vertical groups. A group places its children from left to right (horizontal group) or from top to bottom (vertical group).
A group can surround its child objects with a rectangular frame, an optional title can be displayed to the top of a group, and a flag controls whether space is inserted between the child objects or not.
Balance objects can be placed anywhere between other child objects into a window, mask, or group object. A balance object allows the user to control the weight values of the other child objects and therefore how much space each child gets.
A register group can be used to layout some gui elements into several pages that can be activated one at a time. This is useful if the user interface becomes large and you don't want to spread it over several windows.
Go to the first, previous, next, last section, table of contents.