FF&EZ is a relational database. This simply means that it takes the information you deal with in design projects and organizes it into categories that are related to each other in certain ways. This "relation" is best visualized as a "pointer" to what is called a "parent" in a "parent-child" relationship or the "owner" in an "owner-owned" relationship. That is, the connection is made by pointing to a source of related information using some type of code. To you, the user, this is represented by an "ID" such as a Client ID, Vendor ID or in the case of objects labeled on a drawing, a "Tag." However, in reality, the pointer is hidden from you to prevent it being accidentally mistyped — to create a relationship, you literally point to a target by picking it from a list and system makes the connection for you. If what you need to point to doesn't exist yet, a button will be right there to let you create it. To repeat:

• You build a project by creating the pieces of it in special lists for each type of piece.
• You connect the pieces of the project by simply pointing to them — that is, choosing them from their list.
• If something you need to pick does not exist yet, there will be a convenient way to create it so it appears on the pick list (typically an adjacent New button).

Enter Once, Use Many Times

As an example, the category for vendor information includes the vendor contact, address, etc., while the category for specifications includes information about which vendor, model number, color, etc. Because we can relate the specification category to the vendor category by using a simple abbreviation for the vendor called a "Vendor ID", we only have to enter the vendor name and address once in the system's Vendor List. Whenever a report or screen needs to show the vendor data, it can simply look it up for you using that pointer represented by that ID.¹ 

In the same way, when you place something in a room, you are really only placing a pointer by picking the desired Tag and that links it to everything about that item, contained in the appropriate place elsewhere. If FF&EZ only did this, it would still save you countless hours of typing (and correcting) information about vendors, specifications, rooms and areas. This is because once you point to something, changes you make to it are reflected everywhere it is used (that is, everywhere that points to it).

Changes Are Easy

But further, this also means that if you change something in a vendor's data or change something on a spec (like which vendor was used or how much a product costs), your change is propagated through your whole project without your having to do anything else — because the spec only really "exists" in one place to which everything linked to it points. Note that some things are shared across projects (clients and vendors) while some are only shared within a project (each project has its own separate list of specs so projects do not interfere with each other).

Data-centric vs. document-centric

This approach of "linking" to items that only exist in one place is called "data-centric"  and is one of the great advantages of databases. In contrast, the approach used in spreadsheets² and especially word-processing tends to be "document-centric"—where the layout of the data is essentially the document. In those methods, you must constantly worry that a vendor change has been entered in every place the old vendor was used or that a cost change has been copied to all the rows where that product was used (especially if you have a spreadsheet that divides the project into different room types that use many of the same items). FF&EZ makes this worry a thing of the past. 

However, you must also avoid the trap of thinking in "document" or "spreadsheet row" terms: If you change the source of something that is used in many places, always expect that change to occur in all those places.

A Different Concept of Documentation

In many respects, using FF&EZ's database is like doing a reverse-demolition. When a building is demolished by an expert, many weeks may be spent in preparation, setting charges, linking them with wire, etc. until finally a button is pressed and the building is reduced to pieces in a predetermined order. In FF&EZ, you spend your prep time creating the pieces and "linking" them until finally a report button is pressed and FF&EZ literally builds your building as a report from the pieces you created. Change any of the pieces or the links, and the next time the button is pressed, FF&EZ builds a revised version of the building.

This Should Sound Familiar

The system tracks these categories along their natural relationships (often called "parent-child relationships"), all of them connected via the links described above:

• Clients have Projects.
• Projects have major subdivisions called Areas.
• Areas include Rooms. Rooms can be unique spaces or they can be prototypes, such as a hotel guest room, where you create the room once, then specify a quantity of that room for the project. In FF&EZ, "areas" and "rooms" are not interchangeable terms.
• Rooms contain Objects, the finished "things" that the client sees. Once you create an object in a project, it can be used in as many rooms as needed, using the FFE Worksheet. Objects are made up of one or more Components, such as a chair frame and COM. In the budgeting/programming phase, before any product selection has occurred, objects can also have zero components or (better) "placeholder" components.
• Components are defined by a unique Product Specification. You can create "alternate" specifications, because only those that have been used as a component (in an object that has been placed in a room) will be in the "presentation" reports. The same specification can be used as a component on more than one object (again, you only need to write up a spec once!)
• Specifications are specific items offered by Vendors, although they may also be more generically defined for bidding purposes. A vendor is normally the manufacturer, but you can also add a second vendor as the supplier.
• Specifications that you wish to use on more than one project may optionally be kept in a Library (they can also be imported directly from another project).

Each category has a set of editing forms and functions devoted to maintain information about them. These forms and functions are designed to be quite similar to each other, while still providing time-saving commands appropriate to each item. Later in this Introduction there is a chapter that explains objects and specifications in more detail. Be sure to read this, as well as the Glossary, which defines how specific terms are used.

Watching the Money

Besides reducing typing and manual errors, FF&EZ also gives you a powerful tool to track the budgets and costs for a project. This is a feature that not only reduces your own workload, but increases your capabilities to your clients, since they can rely on you to provide important planning information in many formats. User-defined "code" fields on the area, room, object and specification forms can provide the beginning of both simple analysis for your clients or elaborate custom sub-systems.

Like a spreadsheet, FF&EZ changes related totals whenever you change a number that drives it. Budget and actual cost (price) totals are not only available from printed reports, but can be previewed on your screen as well, so that current totals can easily be seen without need to print the reports.

Quality Control

Finally, by providing a single tool for everyone involved in documenting specifications, FF&EZ gives you a process that will greatly improve your ability to produce high-quality documentation from one project to the next, with much less worry about consistency, information availability, document completeness, last-minute changes and all the other things that can use up valuable time when trying to produce professional work. Special "setup check" queries on the FF&E Worksheet and Object forms can highlight missing or incomplete information before you print presentation or ordering reports.

ąFor those of a technical bent, the actual link between categories is achieved through a hidden ID called a "key." This key is simply a meaningless number that cannot be seen or changed by the user, which means that even the Id on the vendor record can be changed without "breaking" the link to that vendor — the new ID for that vendor simply propagates everywhere the vendor is used. The same is true for Spec IDs, Tags, etc. This means that the phrases "enter the Spec ID" or "change the Room ID" more accurately mean "pick the desired spec" and "pick a different room."

˛Obviously, spreadsheets have great capabilities for linking to single sources of information via formulas. However, most users limit this to values calculated elsewhere in the document, not full-blown vendor or client records referenced multiple times. The problem here is that for normal users, complex formulas are extremely vulnerable to accidental corruption.