Planning your data

Structure of KVS data

Before entering data into KVS, it is important to understand how KVS structures the data that it stores.

Data about people

All data about people (which includes groups and companies) begins with an address. An address represents one "entity" - be this a student, a teacher, or a branch of a company. Whenever one needs to define a new "entity", one begins with an address.

After entering the address, one can then turn this address into a student, teacher, etc. This is done by selecting an existing address in the students, teachers, etc. edit form. This address is then associated with a student, teacher, etc.

Example: a new student has just come in to sign up for a course. To enter this person in KVS, one goes through the following steps:

1. Define a new address
2. Define a new student, and select the address just defined
3. Enter the new booking, and select the student just defined as well as the desired course.

Data about courses

Course types determine the general sorts of courses that you offer. Do you offer private instruction? Semester courses? Courses for small groups and large groups? Intensive courses? These are all factors that distinguish one course-type from another - regardless of the subject matter being studied.

Subjects, on the other hand, define what courses are about - regardless of how the courses are structured. It is generally advisable to define subjects very generally, e.g. "English". However, if you have many courses about a very specific topic (e.g., "English - Business Correspondence"), you may choose to define this as a subject all its own.

When you set up a new course, you select a course type and a subject. Then you select when the course will begin, what course material is required, how often and when the course will meet. Once this is done, you can begin signing up students!

Data about prices

KVS distinguishes between "price names" and the prices themselves. This distinction is important to understand, as it allows you to define a general price structure that applies across various course types.

For example: suppose that you generally want to have a standard price, a 10% discount for mid-sized customers, and a 20% discount for big customers. You can define this structure by defining three "price names", and these price names will be available for each and every course type that you use.

However, the prices for the different course types are completely independent - with the price names, you have only defined the structure. You enter the actual prices for each course-type independently. For example, continuing the example above we might have something like the following:

Because of this flexibility it is neither necessary - nor desirable - to define separate price names for each actual amount charged. Price names should be general - reflecting a company philosophy on discounts, etc. - and the details should be entered for each course type.