Seeing the big picture

[Dimitrios Fkiaras]

Hello and thank you all,

This is my second question in this forum. I am novice in FM and I work for a medium-sized aviation organisation.

(my job there hasn't anything to do with FM). I have a vision of creating a database to hold all data used

by this organisation. 

 

Our organisation has many specialised departments. For example:

a. Personell dpt

b. Training dpt

c. Pilots dpt

d. Technician dpt

e. Logistics dpt

and so on.....

 

So far I have build two databases to keep track of Aircraft spare parts and Flight records.

How does one starts designing such a large database, so that I wont have shortcomings with my ERD- Later?

Bear in mind that I cannot collect all info about the organisations need and then start programming,  and I want to deploy some solutions for certain dpts a.s.a.p.

 

I have a picture in my mind about designing a piece of a puzzle each time and when ready adding it to the existing solution.

I have read about the Data Separation Model and it seems a good idea to keep all data separated from interface.

 

I know its a large subject that I am asking about, I would appreciate any advice or any links to good training sources, preferably low cost or free

Thank you!

 

[sreese]

FileMaker offers a basics guide for free, and the advanced guide isn't that expensive either.

Our solution where I work started out as one FIle and its grown to 60-70 files over the years. It also touches every department.

A suggestion is to try and figure out where data would overlap. IE - Personnel & Pilots, Parts and Airplanes? Airplane and flight records? Then I would try to have data that overlaps in 1 table per overlap type so you can use 1 data set instead of 2 separate ones to update.

IE: You have all of the personnel information, names, address, etc and you take the pertinent information to them being a pilot and have that in one table and put the non pertinent information in a separate table. In a separate table from that I would store the additional pilot information you need (flight hours, aircraft assignments, etc)

When you plan to build in pieces its good to plan for overlap where you know it will happen.

 

[Kris M]

Your thought process can start out big picture and be refined as you go along.

I wouldnt think so much about departments but functional modules.

It is highly likley that modules will align with departments but some modules may need to be cross department functional.

Is there any data that every department/module will need?

People and there information are a big one.

How, where in the system, and who can manage that system wide data is an important factor in designing a long term solution.

You can start small and keep adding pieces but you better get good at moving data around as your system evolves.

[Fitch]

As mentioned above, the FileMaker Training Series is a great place to start. It devotes quite a few pages up front to data modeling.

I'd actually suggest you not do data separation if you're new to FileMaker and database design. If you change your mind down the road, it's easier to split out the data than v. versa.

[Wim Decorte]

11 hours ago, Fitch said:

As mentioned above, the FileMaker Training Series is a great place to start. It devotes quite a few pages up front to data modeling.

I'd actually suggest you not do data separation if you're new to FileMaker and database design. If you change your mind down the road, it's easier to split out the data than v. versa.

Agreed with Fitch, keep it simple for now.  You'll learn a lot as you go along so your solutions will actually in effect be rewritten many times as you progress your learning.  So make it work for your immediate need, then rework as necessary.

Don't fall in the trap of Premature Optimization: https://shreevatsa.wordpress.com/2008/05/16/premature-optimization-is-the-root-of-all-evil/