Every time you wait in line to get grocery money out of an ATM, you are waiting to access a database. Whenever you are asked for your zip code while paying for a DVD at your local audio or video superstore, you are being asked so that the store’s corporate office can track your buying habits in a database (and perhaps track how far you travel to indulge these habits). Even when you go to a public library to find a woodworking how-to book, chances are you’ll use the library’s electronic card catalog (database) to find out on what shelf and in what section your desired book lives.
A database is essentially a structured collection of information stored in an organized manner. Yes, “organized” is a relative term people have rather different views on what constitutes being organized but the definition holds.
When you think of databases, you probably can’t help but think of electronic ones, like the one at the public library or the one in the sales department at your place of business, but even a nonelectronic object could be considered a database, like that dusty recipe box on your kitchen counter, for instance. A recipe box contains a collection of information stored, probably, on index or Rolodex cards. The cards are filed in the box in an intelligent manner, usually alphabetically, maybe also by type of recipe (main course, dessert, or appetizer) separated by tabbed “type” dividers. And, inked on the surface of the cards themselves, the recipe is typed or handwritten in a generally regular way, with a name for each recipe, ingredients in specific quantities, and directions for how to transform the ingredients into the final product.
Beyond the idea that a database holds data, a useful database also allows a user to view the data in meaningful ways, such as by sorting the data, summarizing it, creating meaningful reports based on it, and isolating sets of data by querying it. (Queries are questions asked of the database such as “Give me all customers who live in the state of California” or “Give me the top five sales reps in Dresden, Germany.”)
A good database will also have a pleasant and well-designed interface, that which the user sees and interacts with by clicking with their mouse or entering information from the keyboard. Figure below shows an example of a data-entry screen for a simple recipe database created in FileMaker Pro.
Data-entry screen for FileMaker Pro recipe database
In our recipe box example we introduced a few of the main parts of a database, so let’s give names and definitions to these parts, as shown in below on the following page.
First, we have a table. A table is an object that holds data of only one type, like a recipe. The recipe box, the wooden enclosure itself, is the table in this example.
A much more complex database would comprise many tables. For example, you might have a completely separate table in your database to keep track of the source of each recipe (like Grandma, a magazine article, or a cooking Web site) and then link this source table to your recipe table via a relationship.
A table, in electronic terms, comprises rows and columns; respectively, records and fields in the FileMaker world. A record is one individual set of data in a table. For instance, one of the cards in the box, the recipe for Mama’s Famous Shortbread, would be one record. The next card, Marsha’s Mean Malted Milkballs, would be another record.
A simple recipe box database. The recipe box is the table, and every recipe card is a record in this table; RecipeName is a field that contains a value in every record in this table.
Each record in turn comprises one or more fields, containing individual bits of data. One field on the Mama’s Famous Shortbread recipe (record) is RecipeName, which contains the text data, “Mama’s Famous Shortbread.”
Another field is called Directions, and it contains all the information on how to mix the ingredients, what temperature to preheat the oven to, and how long to let the bread cool when it’s finished baking. If you wanted to get fancy, you would break this information up into two or more unique “directions” fields called MixingDirections, BakingDirections, and so on. Another field in the recipe table might be called RecipeID, which would contain some unique code that you could use to organize your recipes.
Of course, only if you had a degree in mathematics or were, yourself, a robot, would you organize your kitchen’s recipe box this way, but a unique ID or serial number for each record in a table is crucial when developing any relational database system.
File Maker Related Interview Questions
|Management Information systems Interview Questions||Software Engineering Interview Questions|
|File net Interview Questions||Data analyst Interview Questions|
|Hadoop Distributed File System (HDFS) Interview Questions||Linux File Systems Interview Questions|
|Excel Data Analysis Interview Questions||Asp Dot Net Database Interview Questions|
File Maker Tutorial
Getting Comfortable With Filemaker Pro
Your First Database
Records And Data
Developing Relational Databases
Harnessing The Power Of Complex Calculations
Securing Your Filemaker Pro Databases
Sharing Filemaker Pro Databases
Taking Data On The Road
Filemaker, Odbc, And Sql
Filemaker At The Center: Emulating Or Integrating Filemaker Pro With Other Software
Filemaker Pro Plug-ins
Filemaker Pro Development Conventions
Designing, Est Imat Ing, Planning, Developing, And
managing Filemaker Projects
Filemaker Developer, The Developer Tool, And
Developing Commercial Solutions
Web Publishing With Filemaker Pro
Filemaker Pro Unlimited, The Web Server Connector,
And Advanced Web Technologies
Applescript Automation Of Filemaker Pro
Activex Automation For Filemaker Pro
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.