Get started with FileMaker
We are passionate about this still unknown platform FileMaker ... unknown to the general public but is it not just an additional asset? Those who know can hardly do without ... we are among those. Farewell the indigestible databases with control screens resembling the cockpit of yesteryear planes, place to a relaxing conviviality. Connoisseurs know ... since approx. 30 years, yes this product is not a newcomer. He is more than major and in full possession of his means. So for neophytes, here is a small basic training. Happy initiation to FMP!
Links between tables.
Each important information entity can be logically linked to another entity and these links increase the management possibilities. In the actors table, each record represents 1 single actor. In the sheet of each actor one can display the list of the films in which this actor plays a role. In the movie table, each record represents 1 movie only. Each sheet of a movie displays a list of roles and actors who have landed the role. The card of an actor makes it possible to display the list of the roles and films in which these roles found. There is a 1 to many link between a movie and the roles. There is a 1 to many link between an actor and the roles he plays in several movies. It is said that there is a link of many to many between films and actors. Associations are characterized by cardinalities. The choice of cardinalities is essential. This choice is also sometimes debatable, and is therefore the most delicate aspect of modeling. We must make informed choices, knowing however that it is always possible to change a database, when this development does not involve restructuring too important.
Structuring the data.
A database can handle large amounts of information of all kinds. However, a mass of disparate or heterogeneous data does not allow good management. At the base of any effective solution is a reflection on information entities, or on the structure of information. What are we to manage, what are the main 'objects' we need to describe? What are the characteristics of these objects? What exactly are we managing? Let's take a simple case: we want to manage movies. In each film, there can be several actors. Each actor can play in several movies. An actor can also play several different roles in the same movie ... How to solve this problem in a database, knowing that you can not split a movie's sheet or the actor's sheet, for fear to lose the uniqueness of the data? There is inevitably on one side a 'film' entity and on the other an 'actor' entity, but how to represent several actors in the same film? We must create an intermediate entity to the first two: the role! A role is a marriage between a film and an actor. In the same movie, there are many film-actor couples. This requires 3 tables: Movies, Actors and an intermediate table Roles.