Fundamental Concepts of Relational Theory Technical Brief

Transcription

1 Fundamental Concepts of Relational Theory Technical Brief

2 Introduction This paper contains a series of technical briefs intended to provide general information for FileMaker developers regarding some of the fundamental concepts of relational theory. Understanding and being familiar with the basic concepts underlying relational theory can help developers produce better database solutions for their customers. This series of briefs provides a general introduction to the relational model, data normalization, and entity-relationship diagramming (ERD). It also provides a comprehensive glossary of data modeling terms and their relationship to familiar FileMaker terminology. Each brief includes a listing of references and additional resources for the developer wishing to pursue a more in-depth study of the topic. Index A Brief Note Regarding FileMaker Pro and the Relational Model...2 The Origins of the Relational Model...3 Data Normalization...6 Entity-Relationship Diagramming (ERD)...10 Data Modeling Terms & Concepts FileMaker, Inc. All rights reserved. FileMaker and the file folder logo are trademarks of FileMaker, Inc., registered in the U.S. and other countries. All other trademarks are the property of their respective owners. Mention of third party products and companies is for informational purposes only and does not constitute an endorsement nor recommendation. The example companies, organizations, products, domain names, addresses, logos, people, places, and events depicted are purely fictitious, and any resemblance to existing persons and companies is purely coincidental. Product specifications and availability subject to change without notice. FileMaker documentation is copyrighted. By downloading from the FileMaker web site you agree not to make additional copies or distribute this documentation without written permission from FileMaker.

3 A Brief Note Regarding FileMaker Pro and the Relational Model FileMaker Pro has a unified file format, which provides a single set of tools for creating data, business and presentation layers during the application construction. With FileMaker Pro, data is stored, business rules are applied, calculations are derived, and application interface is presented to users, all from one file structure. FileMaker Pro does not force a separation of data, business, and presentation layers upon developers. Unlike traditional RDBMS software, which achieves logical data independence primarily by requiring additional software to extract data, apply business rules and present it to the user. The rules of relational design outlined in these technical briefs apply to the data layer only, not to the business or presentation layers of FileMaker Pro. The business layer is where business rules unique to an organization are applied. FileMaker Pro is exceptionally good at allowing rapid development of business rules driven solutions. The presentation layer supports the user experience, providing an interface with which to navigate records, enter data and format information so that it is meaningful to the user. It is beyond the scope of these articles to discuss an overall design process for creating relational database solutions, if the reader would like information on database design processes that are specifically related to FileMaker Pro development, please see reference materials on page 17. page 2

4 The Origins of the Relational Model It is useful for the FileMaker developer creating relational solutions to have an understanding of the origins of the relational model and the type of problems the model attempts to solve for its users. In computing terms, data is information that has been translated into a form that is more convenient to move or process. Following this definition of data we can describe a database as a collection of data that is organized so that its contents can be easily accessed, managed, and updated. A database contains aggregations of data records or files. A relational database is a collection of data items organized as a set of formally-described tables from which data can be accessed or reassembled in many different ways without having to reorganize the database tables. A relational table is a set of records representing propositions about the real world and can be viewed as representing an entity type with records representing entities of that type. E.F. Codd founded the field of modern database management. He conceived his relational model of databases while working at IBM in He was looking into new ways to handle large amounts of data. In what at the time was a departure from database models and products of the 60 s, Codd, a mathematician, had the idea to apply the discipline and structure of mathematics to data management. Codd s approach took a cue from a branch of mathematics, first-order predicate logic, and was presented in terms of set theory. The term, relation is actually a term first used as a part of set theory. He conceived the relational model primarily as a tool to free users from the frustrations of having to deal with the clutter of storage representation details. Users are not required to know the physical location of a record in order to retrieve its data. 11 Codd developed the relational approach to data modeling as a response to the following requirements: 13 Data independence. Integration of files into databases. Multiple user types. Many online users at terminals. Increased dynamic sharing of data. Networks of mutually remote databases. In 1974 Codd listed the following as the objectives of the relational approach : 13 To provide a high degree of data independence. To provide a community view of the data of spartan simplicity, so that a wide variety of users in an enterprise (ranging from the most computer-naive to the most computersophisticated) can interact with a common model (while not prohibiting superimposed user views for specialized purposes). To simplify the potentially formidable job of the database administrator. To introduce a theoretical foundation into database management. page 3

5 To merge the fact retrieval and file management fields in preparation for the addition at a later time of inferential services in the commercial world*. To lift database application programming to a new level a level in which sets (and more specifically relations) are treated as operands instead of being processed element by element. For Codd the relational approach had four main components: 13 Simplify to the greatest practical extent the types of data structure employed in the principal schema (or community view). Introduce powerful operators to enable both programmers and nonprogrammers to store and retrieve target data without having to navigate to the target. Introduce natural language (for example, English) with dialog support to permit effective interaction by casual (and possibly computer-naive) users. Express authorization and integrity constraints separately from the data structure (because they are liable to change). According to Codd the truly relational system is one that can put many database applications within the nonprogrammer s reach, where programmers were previously a necessity and the fact that relational theory is based on mathematical theory makes the relational database model so structurally sound and is able to guarantee accuracy of its information. This foundation of mathematics also provides the tools necessary to create sound structure as well as guidelines that are used to formulate good design methodologies. 13 In 1974 and 1975 Raymond Boyce and Don Chamberlin of IBM designed a language to extract information from systems based on Codd s relational model known as Structured English Query Language, or SEQUEL, later shortened to SQL. SQL has subsequently become a standard interactive language for executing queries against a relational database, which allows the user to retrieve, insert, delete, and update records within a relational database. 6 An appreciation of the historical origins of the relational model and an understanding of the type of problems the model attempts to solve can help the FileMaker developer produce better database solutions for their customers. References: 1. Codd s 12 Rules. Data Management Strategies, May db_mgr/ /pf_index.html. 2. Data. searchdatabase.com, July ,,sid5_gci211894,00.html. 3. Database. searchdatabase.com, October sdefinition/0,,sid13_gci211895,00.html. (Footnotes) *Inferential Services: being the storage and analysis of the knowledge and the making of inferences from this knowledge, providing to the user much more than the data explicitly carried in data tables. page 4

6 4. Fundamentals of Database Systems (3rd Edition). Ramez A. Elmasri, Shamkant B. Navathe. August ISBN: Introduction to SQL. W3Schools On Relations and Relationships. AccessHelp.net Custom Solutions, http: 7. The Practical SQL Handbook: Using Structured Query Language (3rd Edition). Judith S. Bowman,Sandra L. Emerson (Contributor), Marcy Darnovsky. October ISBN: Relational Database. searchdatabase.com, July Relational Databases. FileMaker, Inc. relationaldb.html (FSA Members Only). 10. SQL. searchdatabase.com, July ,,sid13_gci214230,00.html. 11. The Birth of the Relational Model Thirty Years of Relational. C.J. Date, October 1998 (3-part series) /9810/feat4.shtml, /online2.shtml, online1.shtml. 12. The Relational Database Model. Ryan Stephens and Ronald Plew. May http: //searchdatabase.techtarget.com/tip/1,289483,sid13_gci552875,00.html. 13. Thirty Years of Relational: Relational Forever! C.J. Date, June igententerprise.com/db_area/archives/1999/992206/online1.shtml. For more information on the relational model as it relates specifically to FileMaker Pro see: 14. Advanced FileMaker Pro 5.5 Techniques for Developers. Chris Moyer and Bob Bowers. Plano, Texas: Worldwide Publishing, Inc See: The Relational Model, pg and The Relational Model and FileMaker Pro, pg FileMaker Professional Training Foundation Series. Santa Clara, CA: FileMaker, Inc., See: Relational Design I and Relational Design II. 16. Using FileMaker Pro 5 Special Edition. Rich Coulombre and Jonathan Price. Indianapolis, Indiana: QUE, See: What Makes A Database Relational, pg page 5

7 Data Normalization Data Normalization (normalization) is the process of decomposing large tables into smaller tables in order to eliminate redundant and duplicate data and to avoid problems with inserting, updating or deleting data. Normalization is typically a refinement process engaged in after you have identified the data objects that should be in your database, identified their relationships, and defined the tables required and the columns (fields) within each table. Taking time to properly design your database is the most important step in developing databaseoriented solutions. Normalization should be seen as a process that usually results in the most efficient table structure, and not an absolute rule that must be followed for all the databases you design. Basically it comes down to how to store and retrieve data efficiently. Data normalization makes your data more accurate, easier to analyze, maintain and expand. The processes of data normalization provide for table optimization through the investigation of entity relationships. Table optimization is accomplished through the elimination of all instances of data redundancy (the repetition of data; which can introduce the possibility of error) and nulls. (An entity is the general name for the information that is to be stored within a single table.) The fundamental principle of data normalization is: the same data should not be stored in multiple places. Generally the rules of normalization dictate that redundant information should be moved into new relations (tables). No information is lost in the process, however the number of tables generally increases as the rules are applied. To reconstruct information that once was in one table, a relational query must pull data from more than one table in a join operation (i.e., a portal on a FileMaker layout is actually a relational query that is pulling data from more than one table and can be viewed as a join operation in SQL terms). One should note that in the practical application of the rules of data normalization there is no obligation to fully normalize all records when the actual performance requirements are taken into account. While normalization makes databases more efficient to maintain, they can also make them more complex because data is separated into so many different tables. The major advantages to increased normalization are: 10 It frees the database from certain add, edit, and delete anomalies. It reduces the need to restructure the database as new kinds of data are introduced. It makes the database more informative to users, including different users making different queries. It avoids biasing the database design in favor of certain queries at the expense of others. It allows any relation to be represented as a table (basically because there are no repeating groups). It allows the operations needed for data access to be simpler than they would otherwise have to be. The rules of normalization are referred to as normal forms. The First through Third Normal forms are discussed in more detail below: page 6

8 A table is said to be in First Normal Form (1NF) when: 4 There are no repeating groups. All the key attributes are defined. All attributes are dependent on the primary key. The first normal form sets the very basic rules for an organized database; it requires that elimination of duplicative fields (columns) from the same table, the creation of separate tables for each group of related data, and identifying each record (row) with a unique field or set of fields (the primary key). In essence, 1NF calls for the atomicity of data (one fact per field, cannot be broken into smaller parts without losing meaning11), and the elimination of repeating groups of data through the creation of separate tables of related data. A table is said to be in Second Normal Form (2NF) when: 4 It is in First Normal Form. Each column is dependent upon the entire primary key. The second normal form further addresses the concept of removing duplicative data by removing subsets of data that apply to multiple records (rows) of a table and placing them in separate tables and then creating relationships between these new tables and their predecessors through the use of foreign keys. In essence, 2NF calls for the elimination of redundant data (rows). Example: Consider the following inventory record: PART WAREHOUSE QUANTITY WAREHOUSE-ADDRESS ================= The key here consists of the PART and WAREHOUSE fields together, but WAREHOUSE- ADDRESS is a fact about the WAREHOUSE alone. To satisfy second normal form, the record shown above should be decomposed into (replaced by) the two records: PART WAREHOUSE QUANTITY WAREHOUSE WAREHOUSE-ADDRESS ================= ============ A table is said to be in Third Normal Form (3NF) when: 4 It is in Second Normal Form. It contains no transitive dependencies (where a non-key attribute is dependent on another non-key attribute). The third normal form goes one step further in removing duplicative data by removing fields that are not wholly dependent on the primary key. In essence, 3NF seeks to eliminate all attributes from a table that are not directly dependent upon the primary key. (If an attribute is dependent on anything else it probably should be split out into another table, this is where you often page 7

9 build your lookup tables). A record is in 2NF and 3NF if every field is either part of the key or provides a single-valued fact about exactly the whole key and nothing else. To summarize: First Normal Form: each column must contain only a single value and each row must contain the same columns. Second Normal Form: is in 1NF and each non-key attribute in the relation is functionally dependent upon the primary key. Third Normal Form: is in 2NF and all attributes that are not dependent upon the primary key are eliminated. We can view a normalized table as having all attributes dependent upon the primary key (1NF), the whole primary key (2NF), and nothing but the primary key (3NF). There are additional normal forms: Boyce-Codd NF, 4NF and 5NF, however, they are used relatively less often in business applications and beyond the scope of this introductory technical brief. Following the rules of data normalization, as outlined above, will assist the FileMaker developer in creating solutions, which are easier to analyze, maintain and expand. Solutions with data tables which have been normalized provide the user with more accurate information by eliminating redundant and duplicate data, and avoiding potential anomalies that may occur when adding, updating and deleting data in otherwise non-normalized data tables. References: 1. A Simple Guide to Five Normal Forms in Relational Database Theory. William Kent, September An Introduction to Database Normalization. W.J. Gilmore, Data Normalization Fundamentals. Luke Chung, tpapers/datanorm/index.html. 4. Database Normalization. Database Journal, March 22, Database Normalization Basics. About Web Services. library/weekly/aa080501a.htm?terms=database+normalization+basics 6. Normalization. Steve Litt, Normalization. SearchDatabase.com, November 30, rget.com/sdefinition/0,,sid13_gci212669,00.html. 8. Normalization. Webopedia, June normalization.html. page 8

10 9. On Relations and Relationships. AccessHelp.net Custom Solutions, http: 10. Thirty Years of Relational: The First Three Normal Forms. C.J. Date, March (2-part series) online2.shtml, online2.shtml. For more information on database normalization as it relates specifically to FileMaker Pro see: 11. Advanced FileMaker Pro 5.5 Techniques for Developers. Chris Moyer and Bob Bowers. Plano, Texas: Worldwide Publishing, Inc See: Normalization, pg page 9

11 Entity-Relationship Diagramming (ERD) An entity-relationship diagram is a data modeling technique that creates a graphical representation of the entities, and the relationships between entities, within an information system. (Note that an ERD does not necessarily provide information about all relationships within a FileMaker Pro solution. The ERD represents information about the relationships at the data layer, but nothing about the relationships that you may have created for the business and presentation layers of your solution). There are three main components described by an ERD: 2 The tables of data: usually represented by a rectangle and labeled with a singular noun. The relationship: usually represented by the lines connecting the entities and labeled with verbs. Two files representing separate entities joined together by key fields in order to share data. The cardinality: often represented with crow s feet notation. Cardinality defines the relationship between entities in terms of numbers. The three main cardinal relationships are one-to-one, one-to-many, and many-to-many. Cardinality stems from the fact that some data questions have more than one answer. The steps involved in creating an ERD are: 2 To identify the entities Determine all significant interactions Analyze the nature of the interactions Draw the ERD Sample Entity-Relationship Diagram 1 Note: the symbols used above are not the only way to represent optionality and cardinality in an ERD, there are other alternative symbologies, which you may choose to use when creating your entity relationship diagrams. page10

12 One of the main objectives of the ERD model is to create a simple, easy to understand and convenient presentation of your data model, consisting of entities, attributes, relationships and cardinalities. The ERD model functions as a blueprint for your database design. An ERD is thus a high-level conceptual data-schema. An ERD is developed in early design stages, before any implementation choices are made and should play a major role in the design process of for any significant database system. Briefly, the design process roughly follows these five steps: 3 Requirements collection and analysis Conceptual design Logical design Physical design Implementation If you follow the design steps outlined above, an ERD would be the result of the conceptual design step, and the input for the logical design step. Creating an Entity Relationship Diagram is a way to put your proposed database structures into visual form so you can analyze and improve them. The ERD represents all your entities and relationships; in essence the diagram represents a roadmap for your solution. Drawing an ERD is a step toward defining the technical solution to the business problem your solution is being designed to solve. It also allows you to blueprint out the foundation of your relational database system in a way that can be shared and agreed upon between the designer and the users before the structure has been committed to actual files. An ERD is a tool you use to represent the data layer of your database solution. The ERD will indicate where your data goes, how it gets there, and how it is deleted. It is not the intent of an ERD to depict the solution s business rules, nor how users interact with and navigate the solution; an ERD is strictly intended to represent the data layer of the solution only. Additional References for Readers: 1. Data Modeling. SearchDatabase.com, June sdefinition/0,,sid13_gci211902,00.html. 2. Entity-Relationship Diagram. SearchDatabase.com, December atabase.techtarget.com/sdefinition/0,,sid13_gci333128,00.html. 3. The Entity-Relationship Diagram Technique. Methodology of Information Systems Design Group 3, Cano Koc, Sjors Mollink, Michiel Scheepmaker, February What Exactly IS a Data Model? David Hay (2-part series). http: // page 11

13 For more information on Entity Relationship Diagramming as it relates specifically to FileMaker Pro see: 5. Advanced FileMaker Pro 5.5 Techniques for Developers. Chris Moyer and Bob Bowers. Plano, Texas: Worldwide Publishing, Inc See: Entity Relationship Diagramming, pg FileMaker Professional Training Foundation Series. Santa Clara, CA: FileMaker, Inc., See: Creating an Entity-Relationship Diagram, pg. 4A-9 through 4A Using FileMaker Pro 5 Special Edition. Rich Coulombre and Jonathan Price. Indianapolis, Indiana: QUE, See: Create An Entity Relationship Diagram, pg page 12

14 Data Modeling Terms & Concepts Attribute A special kind of predicate that describes things according to some domain, e.g., weight of a package, distance to some destination, etc. Attributes are pieces of information that describe entities. An entity can have various characteristics, or attributes. An attribute can be thought of as a field on a record, with various values possible. If an attribute does not apply to every entity in the class, you may have discovered a separate entity. You may have mistakenly assigned attributes to Entities if you have more than one piece of information in a single field too, for instance: Student has advisors name, but you try to fit Advisor name, phone number and address into that field. An attribute has one value for each instance, but no more than one value per instance. It may be helpful to think of an attribute as a column in table view (or a field in form view in terms of a FileMaker Pro file). Class A group of entities (records) based on having the same set of predicates (attributes, fields, columns) which results in each entity pertaining to one and only one class. The concept of class becomes a table. Example: Customers Customer ID Customer Name Street City State Zip Code Credit Limit Column Database tables are composed of individual columns (fields) corresponding to the attributes of the object. Example: In the following database table, the columns are <name, ID, extension> Name ID Extension Andrew Rick Cris Jay Data In computing, data is information that has been translated into a form that is more convenient to move or process. Relative to today s computers and transmission media, data is information converted into binary digital form. Data consists of a series of facts or statements that may have been collected, stored, processed and/or manipulated but have not been organized or placed into context. When data is organized meaningfully, it becomes information. page13

15 Database A database is a collection of data that is organized so that its contents can easily be accessed, managed, and updated. The most prevalent type of database is the relational database, a tabular database in which data is defined so that it can be reorganized and accessed in a number of different ways. Data Modeling Data modeling is the analysis of data objects that are used in a business or other context and the identification of the relationships among these data objects. As a result of data modeling, you can then define the classes that provide the templates for program objects. Domain Describes, but cannot be described; seen in value lists, data validation rules, etc. A system of values used to measure a quality of an object or experience. Entity A group of predicates (fields) based on having the same argument which results in each predicate pertaining to one and only one entity. The concept of entity becomes a record. A group of entities is an instance of a class. Field A field (attribute, column) is a single unit of data stored as part of a database record. Each record (row) is made up of one or more fields, which corresponds to the columns in a database table. Fields are often also referred to as attributes. Foreign Key A foreign key is a column, or combination of columns, that contain values that are found in the primary key of some table (including, possibly, itself). A foreign key may be null, and almost always is not unique. A foreign key is a field in a relational table that matches the primary key column of another table. The foreign key can be used to cross-reference tables. Join A relational operator. A join is used to display values from multiple related tables. Normalization Normalization is the process of structuring relational database schema such that most ambiguity is removed. The stages of normalization are referred to as normal forms and progress from the least restrictive (First Normal Form) through the most complete (Fifth Normal Form). Predicate Predicates describe things; it is any relevant property, quality, or characteristic ascribed to a thing. A database can be seen as just a bunch of Predicates, because behind the scenes, Predicates become the fields in records. 3 page 14

16 Primary Key A primary key is a table column that can be used to uniquely identify and reference every row of the table. Any column that has this property will do these columns are called candidate keys. A table can have many candidate keys but only one primary key. The primary key cannot be null. The primary key of a relational table uniquely identifies each record in the table. It can either be a normal attribute that is guaranteed to be unique (such as Social Security Number in a table with no more than one record per person) or it can be generated by the database. You get to a particular piece of data by referencing the primary key. Query A query (noun) is a question, often required to be expressed in a formal way. In computers, what a user of a search engine or database enters is sometimes called the query. To query (verb) means to submit a query (noun). A database query can be either a select query or an action query. A select query is simply a data retrieval query. An action query can ask for additional operations on the data, such as insertion, updating, or deletion. FileMaker allows for the use of relationships as a stored queries or views, i.e., +Sum (invoices by g_territory_state:: invoice_total), GTRR, filtered portals, etc. In FileMaker queries or views are often stored in relationships. RDBMS A relational database management system (RDBMS) is a program that lets you create, update, and administer a relational database. An RDBMS takes Structured Query Language (SQL) statements entered by a user or contained in an application program and creates, updates, or provides access to the database. Any system that claims to be a RDBMS must be able to manage databases entirely through its relational capabilities. Record A database record consists of one set of tuples (records) for a given relational table. In a relational database, records correspond to rows in each table. Relation A database relation is a predefined row/column format for storing information in a relational database. Relations are equivalent to tables. As noted by Fabian Pascal; formally a relation is a special set of tuples, representing propositions about the real world. Informally a relational table can be viewed as representing an entity type with rows representing entities of that type. 6 Relational Database A relational database is a collection of data items organized as a set of formally-described tables from which data can be accessed or reassembled in many different ways without having to reorganize the database tables. The relational database was invented by E. F. Codd at IBM in page 15

17 Relationship The essence of the relationship is not the link; the value of the relationship is what it tells you about the entity being described. By convention, the relationship name always contains a verb; this convention allows the entire structure to be read as a sentence. The name of the relationship must convey an understanding of how the data is to be used. A clear relationship name encourages people to make informed choices about how a relationship should be used. 3 Row In a relational database, a row consists of one set of attributes (or one tuple) corresponding to one instance of the entity that a table schema describes. Also known as a record. Stored Procedure A stored procedure is a set of statements with an assigned name that s stored in the database in compiled form so that it can be shared by a number of programs. The use of stored procedures can be helpful in controlling access to data (end-users may enter or change data but do not write procedures), preserving data integrity (information is entered in a consistent manner), and improving productivity (statements in a stored procedure only need to be written one time). (Note that technically a stored procedure is a violation of the data independence rule of the relational model). Table A table in a relational database is a predefined format of rows and columns that define an entity. Trigger In a database, a trigger is a set of Structured Query Language (SQL) statements that automatically fires off an action when a specific operation, such as changing data in a table, occurs. A trigger consists of an event (an INSERT, DELETE, or UPDATE statement issued against an associated table) and an action (the related procedure). Triggers are used to preserve data integrity by checking on or changing data in a consistent manner. (Note that technically a trigger is a violation of the data independence rule of the relational model. Tuple A term from set theory, which refers to a collection of one or more attributes. FileMaker Equivalent Terms Although there is not always a direct translation of FileMaker terminology to traditional relational database terminology, the table below shows how FileMaker terms can be translated into their classic relational database equivalents. Relational Term Database Row, entity, tuple, record Table, class, relation Predicate, attribute, column Query Primary key Foreign key Stored-procedure, trigger Domain FileMaker Term Solution, application Record File Field Find, relationships (used as stored queries) Match-Field, primary key Match-Field, foreign-key Script or calculation Value list, field validation options page 16

18 Definition of FileMaker of Pro FileMaker Pro is a software application for individuals and workgroups with relational database functionality, and rich graphical, networking, and data exchange capabilities that allows nonprogrammers to create database solutions that encapsulate their unique business rules. Additional References for Readers: 1. Advanced FileMaker Pro 5.5 Techniques for Developers. Chris Moyer and Bob Bowers. Plano, Texas: Worldwide Publishing, Inc See: Entity Relationship Diagramming, pg An Introduction to Database Systems. Seventh Edition. C.J. Date. Reading, MA: Addison-Wesley Data Modeling For Information Professionals. Bob Schmidt. Upper Saddle River, New Jersey: Prentice-Hall PTR, Database Design for Mere Mortals. Second Edition. Michael J. Hernandez. Boston, MA: Addison-Wesley Databases Glossary. About.com: Databases. glossary/blglossary.htm?pm=ss13_databases. 6. The Relational Database Model. Ryan Stephens and Ronald Plew. May http: //searchdatabase.techtarget.com/tip/1,289483,sid13_gci552875,00.html. 7. Relational Database Design and FileMaker Pro: MacWorld Power Tools Workshop. Andrew LeCates, January Using FileMaker Pro 5 Special Edition. Rich Coulombre and Jonathan Price. Indianapolis, Indiana: QUE, FileMaker Pro Development Resources 1. Advanced FileMaker Pro 5.5 Techniques for Developers. Chris Moyer and Bob Bowers. Plano, Texas: Worldwide Publishing, Inc The six D s of database development a process framework for developing FileMaker solutions: Discover, Define, Design, Develop, Deploy and Denouement. Cris Ippolite. isolutions, Inc. Santa Monica, CA Using FileMaker Pro 5 Special Edition. Rich Coulombre and Jonathan Price. Indianapolis, Indiana: QUE, page 17