Best Airtable Examples

1. Best Air Table Examples For A
2. Best Air Table Examples Pdf
3. Airtable Blocks

Each year I revamp how I'm setting and tracking my goals, and each year the system gets a little better.

Last year, I was using some combination of Asana for the first half of the year, and then added in a Google Sheet as outlined in my productivity article.

Even with the Google Sheet, the system seemed a little haphazard. It wasn't easy to track the relationships between my Annual, Monthly, and Weekly goals. And the arbitrary 3 goals per day felt forced at times.

The Best Nonprofit Use-Case Examples for Airtable Using Airtable as a Donor Database. As a nonprofit organization, your donors are one of the most important indicators of long-term success. Donors provide vital funds to keep your organization operating. A donor management system is essential to keeping track of individuals, companies,. The Best Airtable Examples and Use Cases Time magazine team uses Airtable as a database to keep track of production expenses, invoices, and other content-related processes. Automated email notifications integrated into the solution allow freelance team members to stay on top of their payment status. Take our free Airtable Crash Course!

What I've been wanting is a way to track my Daily, Weekly, Monthly, Quarterly and Annual goals in one place, with good visibility on what each daily goal is supporting at the macro level.

After some finagling with different apps, I think I've finally built a good solution in Airtable.

This system lets you:

1. Easily track your Yearly, Quarterly, Monthly, Weekly, and Daily goals.
2. Move between the different levels of your goals quickly to see how they fit together.
3. Reflect on how each period is going.

But most important, it makes it stupid-simple to plan out short term actions that will best impact your long term goals. It lets you take big, harder to target goals and break them down into the simple steps you can take each day to make it more likely you'll achieve them.

And it does it all with pretty colors, which is always a plus.

If you want to implement this yourself, I have an Airtable template you can make a copy of to make things easier.

Your Annual Goals

It starts with the annual goals, whatever you want to accomplish for the year. I generally try to make these a bit aggressive, since I'd rather push harder at more unlikely goals than easily achieve a bunch of less meaningful ones. Here's a snapshot of some of them:

I break these out by a few categories: Personal, Physical, Financial, Influence, and Business.

Personal Goals are ones related to, well, anything personal and social. This is kind of a catch-all for things that'll make my life better.

Physical Goals are anything related to improving my health.

Financial Goals are specifically related to money and investing.

Influence Goals are for this site, Made You Think, and the Medley.

Business Goals are for Growth Machine, Cup & Leaf, The Writer Finder, and any other business-y projects I have going on.

Adding categories for the goals at this level is mostly useful for making sure I'm not neglecting any area. It's easy for me to come up with physical goals, for example, but I'm not always great at coming up with Personal goals.

Then each Annual goal has a few more columns:

• Deadline is the Quarter I want to accomplish the goal by the end of.
• Status is a way to track if I've started or completed the goal.
• Baseline is where I was at the start of the year.
• Project Link is where I can put a link to a related Asana project, as relevant.

And finally, there's a 'check in' column for each month of the year where I can log what progress I made on it. This gives a useful birds-eye view of how the year is going as it progresses, and makes it easy to reflect at the end of the year.

Your Quarterly Goals

From the annual goals, it's easy to plan out what your goals for the quarter will be. I get rid of the categories at this point, and just list out each goal for the quarter, with a target month it'll be done by, and then organized by status (Not Started, In Progress, Complete):

I think the Quarterly goals are the least important of the different levels, since you can capture it within your monthly goals fairly well.

If I were going to get rid of one of the sheets this would probably be it, but I like being able to see how everything is going on a 3-month timescale so I don't always have to go through backing my weekly and monthly goals into the yearly goals.

Your Monthly Goals

Monthly goals get the same structure as the Quarterly goals. I take the Quarterly goals, set Monthly goals based on making the best progress I can towards them, and then track them based on their completion status.

In the 'Notes' column, I'll track either how close I am to hitting that goal (like having done 1 of the 4 articles for the month), or link to a related Asana project where I have a more detailed task list.

Weekly Goals and Daily Goals

I track the Weekly and Daily goals together, since they're essentially the same thing. Any weekly goal can be done in a couple of days, so having one sheet where you can see everything you want to get done that week is helpful:

You'll notice this is set up differently from the Monthly and Quarterly goals. I have it grouped by the Day each goal is due, and then have it set to hide any goal once I check it off in the Checkbox column.

Each goal also has a week number assigned to it (4, in this example), which lets me keep track of what all my goals were each week in the past, in case I want to go back and look at how progress has been going.

Last, to be clear this isn't a task list. These are more the 'most important things' where if I get them done on that day, it'll be a productive day and I'll make meaningful progress towards my goals for the week. Things I'm going to do anyway don't go in here, nor do the myriad of mostly Growth Machine related things I need to do that are in Asana.

Goal tracking, to me, is most importantly about doing the things that won't get done on their own. All of these goals would be easy to ignore in favor of the seemingly urgent other work, which is why this kind of goal tracking is so useful.

So each day, I'll take the goals in Airtable I have for the day, add them to Asana, and get to work.

Best Air Table Examples For A

Reflecting and Setting New Goals

One mistake I see people make with this kind of goal tracking is trying to set goals too far in advance, like planning out the goals for January, February, and March at the start of the quarter.

I intentionally don't do this because I think you're much more likely to overperform, underperform, or deviate from your goals in some unexpected way than makes planning too far in advance kind of pointless.

Instead, I don't plan the next periods goals until the end of the previous period. So on Friday, I'll take some time to clean up my goals from that week and plan the goals for next week. At the end of the month, I set the goals for next month. At the end of the quarter, I set goals for the next quarter.

As I'm doing that, I might find that some goals no longer make sense, or need to be adjusted, at higher levels in the system. That's totally fine, and I think an important part of the process. You don't want to let yourself off easy from tough goals, but you also don't want to force yourself to keep pursuing something or some direction that no longer make sense.

Further Modifications

This is meant to be a flexible, adaptable system to however you like to set and track your goals.

One thing you might add is a longer term view, like five or ten year goals. Taylor Pearson uses a similar system, where he goes all the way up to 25 year goals.

You could add Life Goals, you could add a Habit tracker, you could go down to Hourly level tracking… go crazy. Airtable is pretty flexible for this kind of structured data, and I've been enjoying using it for this and my personal CRM.

Have fun with it, and let me know what modifications you come up with on Twitter.

If you need to streamline your team's operations, ensure that multiple teams in your org are working from a single source of truth, maintain a canonical inventory, or perform any other database?

So clearly, good database design is important when trying to build a database that works for you. But what does it actually mean for a database to be well-designed?

A well-designed database enforces data integrity

Data integrity refers to the overall accuracy, completeness, and consistency of the data in your database; a well-designed database maintains data integrity by implementing the processes and standards proposed during the design phase.

Data integrity includes three specific technical aspects of a relational database's structure:

• Entity integrity (or table-level integrity) ensures that a table has no duplicate records, and that the values of the table's primary keys are all unique and not null.
• Domain integrity (or field-level integrity) ensures that the purpose of every field is clear and identifiable, and that the values in each field are valid, consistent, and accurate.
• Referential integrity (or relationship-level integrity) ensures that the relationships between pairs of tables are sound, so that the records in the tables are synchronized whenever data is entered into, updated in, or deleted from either table.

A well-designed database enforces relevant business rules

Every organization does its work a little differently, and as such, each organization has its own unique requirements for its data, also known as business rules. Some hypothetical examples might be: a video production company requires that the duration timestamps for its video files be stored in milliseconds; a consumer brand requires that each product in its catalog be assigned a unique eight-character alphanumeric code; a university requires that its students sign up for no more than six classes per semester.

Ideally your team's database should be able to enforce your unique business rules; this will ensure that the data coming into your base is both accurate and useful. For example, if the university in the previous example forgot to account for their business rules when building their database, a student might try to sign up for 20 classes in a single semester—creating a mess for a database administrator to clean up later.

How to design your relational database, step by step

If this all sounds unfamiliar or overwhelming, don't worry—there is a systematic process you can follow that will ensure your relational database follows good design principles, is well-suited to your organization's needs, and avoids common pitfalls.

Step 1: define your purpose and objectives

Before beginning your database design journey, it's worth taking a step back and answering a very important question: 'Why am I making this database?' Are you making this database in order to manage business transactions? To store information? To solve a particular organizational problem? Whatever the case, it's worth taking the time to identify the intended purpose of the database you'll be creating.

You may even wish to work together with managers, leadership, and end users to jointly write out a mission statement for your database, like: 'The purpose of the Mingei International Museum database is to maintain the data for our art collection,' or 'Zenbooth's database will store all of the data for our manufacturing resource planning.'

Additionally, you should define the objectives that the end users of the database will have: which specific tasks will the end users need to perform in order to accomplish their work? Developing an explicit list of objectives—like 'Know the status and location of each of the pieces of art in our collection at all times,' 'Produce monthly reports on customer sales,' or 'Maintain complete records for each of our clients'—will help you determine an appropriate structure for your database as you work through this design process.

Step 2: analyze data requirements

Before you begin designing your database, you'll need to analyze your organization's data requirements. This might sound intimidating, but all it means is that you'll be assessing how your team currently does its work, and identifying what kind of data is most important to that work. You can do this by closely examining existing processes and by interviewing team members—both management and end users. Some questions to ask as you conduct your research:

• How is your organization currently collecting data? Are you using spreadsheets? Paper templates? Another database? Whichever of these methods you're using, find the most complete samples of work that you can, and look through them to find as many different attributes as you can. For example, your editorial calendar might currently be living in a spreadsheet, and have columns for 'Author,' 'Due Date,' 'Editor,' and so on.
• How is your organization currently presenting data? What kinds of reports does your organization use? PDFs? Slide decks? Web pages? Carefully examine any types of presentations that incorporate data from your current data collection methods and use them to identify potential fields.
• How are your team members currently using data? The best way to determine the answers to this question is by talking to team members—both management and end users—to identify their current data use patterns as well as any gaps in the current system. You can ask questions like, 'What types of data are you currently using?' and have them review the samples you collected. Importantly, these interviews can also illuminate plans for the future growth of the organization, which will give you some insight into future information requirements.

Step 3: create a list of entities and a list of attributes

After settling on your organization's purpose and objectives, and analyzing your data requirements, the next steps are to extract a list of entities and a list of attributes from the body of research you've compiled. In the context of relational databases, an entity is an object, person, place, event, or idea—like 'clients,' 'products,' 'projects,' or 'sales reps.' Attributes are the defining characteristics of those entities, like 'name,' 'quantity,' 'address,' 'phone number,' or 'genre.' One way you can think about this is that entities are like nouns, and attributes are like the adjectives that describe those nouns.

Start by picking out entities from your research and putting them on a list. These entities will eventually serve as a guide to help you define your tables later on in the design process, but they will also help you identify the attributes necessary to create your list of fields. For example, if you were developing a talent database for a record label, your entities list might look something like this:

• Artist
• Agent
• Venue
• Gigs
• etc.

Next, create a separate list containing the relevant attributes for each of the entities you've identified, as well as any other attributes that might have come up during your research. These attributes will define the fields for your tables. Again, for the talent database example, your attributes list might look something like this:

• Artist Name
• Artist Phone Number
• Agent Name
• Agent Phone Number
• Agent Email Address
• Venue Name
• Venue Address
• Gig Dates
• etc.

Once you've collected a preliminary list of attributes, you should go through and refine them to make sure that they accurately represent your organization's informational needs.

Tips:

• If multiple attributes have different names but actually represent the same concept, deduplicate them so there's only one. For example, if you have both 'Product No.' and 'Product Number' on your list, you should remove one of them.
• If multiple attributes have similar names but actually represent different concepts, rename the attributes to be more specific. For example, you could rename two different 'Name' attributes into the more specific 'Artist Name' and 'Venue Name.'

After refining your lists, it's a good idea to review these lists that you've compiled with some of the team members you interviewed to confirm that you've accounted for every necessary type of data. Be sure to take their feedback into consideration and further refine your lists as appropriate.

Step 4: model the tables and fields

After creating your lists of entities and attributes, your task is to use those lists to design the structure of your relational database. Your list of entities will become the different tables in your base, and the list of attributes will become the fields for these tables.

Take your lists and assign each of the attributes to your tables. For example, after we finish assigning our listed attributes to our new tables, our talent management database-in-planning might look something like this:

Next, you need to pick an appropriate primary key field for each table. A primary key is a major component of ensuring data integrity, as it uniquely identifies each record within a table and is used to establish relationships between different tables.

Each table's primary key field should meet the following criteria:

• It must contain unique values. This will prevent you from creating duplicate records within a table.
• It cannot contain null values. A null value is the absence of a value, and as such, you cannot use a null value to identify a record.
• It should not be a value that will need to be modified often. Ideally, primary key values will remain relatively static over time and only be changed under rare circumstances.
• It should not be sensitive personal information. Social security numbers, passwords, personal health information (PHI) and other sensitive data may be unique, but should not be used as primary keys, as doing so makes it much harder to keep this data appropriately secured in a single location.
• Ideally, it uses the table name as part of its own name. While not strictly necessary, having the table name in the primary key field name can make it easier to identify the table from which the primary key field originated. For example, 'Employee Name' would be obviously identifiable as coming from the 'Employees' table.

It might be possible that your preliminary list of fields for a given table does not contain one single field that meets all these criteria. However, you may be able to combine two or more fields to create a separate, unique field which does meet all these criteria. For example, you could combine the values in a 'Given Name' field and a 'Surname' field to create a third, calculated 'Full Name' field using a concatenation formula.

In the event that this strategy still doesn't work for your purposes, you can always manufacture a new field designated specifically for unique identification codes to serve as your primary key field. Fields like 'Product ID' or 'Sales Invoice Number' are often created for this purpose.

Let's return to our talent management database example. For the 'Artists' table, the 'Artist name' field is already a pretty good candidate for the primary key, as it's pretty unlikely that your record label will sign two artists with the same name. We can also pick 'Venue name' as the primary key for the 'Venues' table. For the other tables, however, it would probably be better to make new fields that concatenate values from existing fields. In the 'Agents' table, we might make a new field—'Agent full name'—that concatenates the values of the 'Agent given name' and 'Agent surname' fields. For the 'Gigs' table, an artist could perform at the same venue on multiple occasions, so we should make a new field that gives a unique name to the specific combination of an artist at a venue on a specific date. You could potentially concatenate the name of the artist, the venue, and the date to create values like '2 Linkz at the Gotham City Metro Club, 02/13/2019,' but that can get long and unwieldy fast. Alternatively, you could try creating a new field—'Gig code'—with unique alphanumeric code values (like 'E0023'). Whichever approach you take is up to you and your team's specific needs.

Step 5: establish table relationships

Once you've identified your tables, fields, and primary key fields, you can start the process of linking them all together. Using your knowledge gained from your prior research and conversations with other team members, you can make a preliminary attempt to define the logical relationships between your different tables.

Relationships between tables are created by linking together primary key fields and foreign key fields. A foreign key is a field in one table that references the primary key of another table. For example, if you were designing a sales pipeline database, your 'Deals' table might contain a 'Sales Rep' foreign key field, which would link to your 'Sales Reps' table; if you were designing a content calendar database, your 'Pieces' table might contain an 'Editor' foreign key field and an 'Author' foreign key field, both of which would link to your 'Staff' table.

To start defining the relationships between your different tables, identify the potential foreign key fields. In an ideal relational database, foreign key fields are the only fields that should ever be duplicated, so if you identify any fields that appear in multiple tables, those are likely candidates for foreign key fields.

Returning to our talent agency example, we can go through our lists of fields per table and identify the fields that share names/concepts with the primary key fields of other tables:

There are three types of relationships between tables:

• One-to-one relationships, in which a record in one table is related to one and only one record in another table. An example of this might be an IT team's asset tracking database with an 'Employees' table and a 'Computers' table: each employee only possesses one company-owned computer, and each company-owned computer is possessed by only one employee. (Note that one-to-one relationships are relatively uncommon.)
• One-to-many relationships, in which a record in one table can be related to one or more records in another table. An example of this might be a project tracker database which contains a 'Projects' table and a 'Tasks' table: each project has multiple associated tasks, but each task is only associated with one project.
• Many-to-many relationships, in which one or more records in one table can be related to one or more records in another table. An example of this might be an inventory of books, which contains a 'Titles' table and an 'Authors' table: each title will have been written by one or more authors, and each author can have written one or more books.

Being able to identify the different types of relationships is helpful for modeling your organization's business rules. For example, if you specifically define a relationship as one-to-many, you can enforce a rule that the records on the 'many' side of the relationship can, indeed, only ever be linked to one record in the other table. (More on this in the next step.)

One activity that can be very helpful for visualizing how your tables will relate to each other is creating an entity-relationship diagram, or an ER diagram. An ER diagram is a kind of chart that uses shapes to represent your tables and lines to represent the relationships between your tables.

You might be wondering why you would want to go through the effort of establishing the relationships between these tables. The main reason is that the table relationships actually allow you to make logical connections between pairs of tables, which in turn allows you to draw data from multiple tables simultaneously. Being able to draw data from multiple tables simultaneously means that you can make your tables more efficient and minimize redundant data. If you construct your table relationships appropriately, you can see whatever data you need to see from any table, at any time, but you'll only ever need to enter it or modify it in a single location.

To better understand how this might work in practice, let's return once again to our talent agency example. Suppose you wanted to be able to see at a glance how much revenue each artist has generated in total across all their gigs. Because you've already established a relationship between the 'Gigs' and the 'Artists' table, you can use that relationship to look up data from all the relevant gig records per artist.

To do this, you can create a new computed field in the 'Artists' table—'Total gig revenue'—that sums the total value of 'Revenue generated per gig' for all linked records in the 'Gigs' table per artist. A computed field is a special kind of field that automatically generates a value using one or more values from another field in the database. Because the computed field updates automatically, if you ever edit a value in the 'Revenue generated per gig' field or add any new gig records for a particular artist, the 'Total gig revenue' field will also update automatically.

You can even take this one step further: if you wanted to see how much revenue each agent has generated in total through all the artists they manage, then you could use the established relationship between the 'Artists' and the 'Agents' table and create a new computed field in the 'Agents' table—'Artists' total gig revenue'—that sums the total value of 'Total gig revenue' for all linked records in the 'Artists' table per agent. Since this new computed field in the 'Agents' table is connected to the 'Gigs' table via the 'Artists' table, it will also be updated automatically if the values in the 'Gigs' table change, even though there is no direct relationship between the 'Gigs' and 'Agents' tables.

Step 6: establish business rules

After fully establishing the overall structure of your database, it's time to incorporate your organization's unique business rules into your database design. Because business rules are so closely tied to the specific ways in which your organization does its work, your most valuable resource will be, once again, managers and end users. Consulting with them can provide invaluable insight into which constraints will be the most impactful for your workflows.

Generally speaking, there are two main kinds of business rules. Field-specific business rules refer to constraints placed on specific fields. Some examples of field-specific business rules might be 'Dates on our product order invoices must be displayed in the ISO format ‘2020-12-22,'' 'Email addresses stored in the employee directory must be valid email addresses,' or 'The only valid values that can be selected for this status field are ‘To do,' ‘Doing,' and ‘Done.''

Relationship-specific business rules, which we briefly touched on earlier, refer to constraints placed on table relationships. Some examples of relationship-specific business rules might be 'Each project in our video production tracker must be linked to one or more fact-checkers,' or 'Each line item in a customer's order must be linked to one and only one product.'

Best Air Table Examples Pdf

The most thorough method of identifying and implementing your field-specific business rules is to systematically review each field within each table to determine which business rules apply to that field. Every field will have some relevant business rules, even if those rules are as general as 'Every value in the ‘Employee first name' field should be a string composed of letters.' In a similar fashion, you can systematically review each of the relationships in your proposed database structure and assess whether or not they require any relationship-specific business rules.

In the future, you will probably need to change your existing business rules or add new business rules. For example, your team might decide that 'Canceled' should be a valid potential value for a task status field that currently includes only 'To do,' 'Doing,' and 'Done' as options. Fortunately, if you have followed the previous steps and set up a robust underlying database structure, it should be relatively easy to adjust your field- and relationship-specific business rules down the road without having to restructure your entire database.

Step 7: check your work

You're almost done with the database design process—all you need to do is perform one final review of your database. A few questions to ask yourself as you look over every table, field, and relationship:

• Does every type of entity have its own dedicated table?
• Are there any tables that might need to be consolidated, or, conversely, decomposed into multiple tables?
• Are there any duplicate fields in my database that are not foreign keys?
• Do each of my fields have defined specifications that match our organization's business rules?
• Do the relationships between my tables make sense?

Last year, I was using some combination of Asana for the first half of the year, and then added in a Google Sheet as outlined in my productivity article.

Even with the Google Sheet, the system seemed a little haphazard. It wasn't easy to track the relationships between my Annual, Monthly, and Weekly goals. And the arbitrary 3 goals per day felt forced at times.

The Best Nonprofit Use-Case Examples for Airtable Using Airtable as a Donor Database. As a nonprofit organization, your donors are one of the most important indicators of long-term success. Donors provide vital funds to keep your organization operating. A donor management system is essential to keeping track of individuals, companies,. The Best Airtable Examples and Use Cases Time magazine team uses Airtable as a database to keep track of production expenses, invoices, and other content-related processes. Automated email notifications integrated into the solution allow freelance team members to stay on top of their payment status. Take our free Airtable Crash Course!

What I've been wanting is a way to track my Daily, Weekly, Monthly, Quarterly and Annual goals in one place, with good visibility on what each daily goal is supporting at the macro level.

After some finagling with different apps, I think I've finally built a good solution in Airtable.

This system lets you:

1. Easily track your Yearly, Quarterly, Monthly, Weekly, and Daily goals.
2. Move between the different levels of your goals quickly to see how they fit together.
3. Reflect on how each period is going.

But most important, it makes it stupid-simple to plan out short term actions that will best impact your long term goals. It lets you take big, harder to target goals and break them down into the simple steps you can take each day to make it more likely you'll achieve them.

And it does it all with pretty colors, which is always a plus.

If you want to implement this yourself, I have an Airtable template you can make a copy of to make things easier.

Your Annual Goals

It starts with the annual goals, whatever you want to accomplish for the year. I generally try to make these a bit aggressive, since I'd rather push harder at more unlikely goals than easily achieve a bunch of less meaningful ones. Here's a snapshot of some of them:

I break these out by a few categories: Personal, Physical, Financial, Influence, and Business.

Personal Goals are ones related to, well, anything personal and social. This is kind of a catch-all for things that'll make my life better.

Physical Goals are anything related to improving my health.

Financial Goals are specifically related to money and investing.

Influence Goals are for this site, Made You Think, and the Medley.

Business Goals are for Growth Machine, Cup & Leaf, The Writer Finder, and any other business-y projects I have going on.

Adding categories for the goals at this level is mostly useful for making sure I'm not neglecting any area. It's easy for me to come up with physical goals, for example, but I'm not always great at coming up with Personal goals.

Then each Annual goal has a few more columns:

• Deadline is the Quarter I want to accomplish the goal by the end of.
• Status is a way to track if I've started or completed the goal.
• Baseline is where I was at the start of the year.
• Project Link is where I can put a link to a related Asana project, as relevant.

And finally, there's a 'check in' column for each month of the year where I can log what progress I made on it. This gives a useful birds-eye view of how the year is going as it progresses, and makes it easy to reflect at the end of the year.

Your Quarterly Goals

From the annual goals, it's easy to plan out what your goals for the quarter will be. I get rid of the categories at this point, and just list out each goal for the quarter, with a target month it'll be done by, and then organized by status (Not Started, In Progress, Complete):

I think the Quarterly goals are the least important of the different levels, since you can capture it within your monthly goals fairly well.

If I were going to get rid of one of the sheets this would probably be it, but I like being able to see how everything is going on a 3-month timescale so I don't always have to go through backing my weekly and monthly goals into the yearly goals.

Your Monthly Goals

Monthly goals get the same structure as the Quarterly goals. I take the Quarterly goals, set Monthly goals based on making the best progress I can towards them, and then track them based on their completion status.

In the 'Notes' column, I'll track either how close I am to hitting that goal (like having done 1 of the 4 articles for the month), or link to a related Asana project where I have a more detailed task list.

Weekly Goals and Daily Goals

I track the Weekly and Daily goals together, since they're essentially the same thing. Any weekly goal can be done in a couple of days, so having one sheet where you can see everything you want to get done that week is helpful:

You'll notice this is set up differently from the Monthly and Quarterly goals. I have it grouped by the Day each goal is due, and then have it set to hide any goal once I check it off in the Checkbox column.

Each goal also has a week number assigned to it (4, in this example), which lets me keep track of what all my goals were each week in the past, in case I want to go back and look at how progress has been going.

Last, to be clear this isn't a task list. These are more the 'most important things' where if I get them done on that day, it'll be a productive day and I'll make meaningful progress towards my goals for the week. Things I'm going to do anyway don't go in here, nor do the myriad of mostly Growth Machine related things I need to do that are in Asana.

Goal tracking, to me, is most importantly about doing the things that won't get done on their own. All of these goals would be easy to ignore in favor of the seemingly urgent other work, which is why this kind of goal tracking is so useful.

So each day, I'll take the goals in Airtable I have for the day, add them to Asana, and get to work.

Best Air Table Examples For A

Reflecting and Setting New Goals

One mistake I see people make with this kind of goal tracking is trying to set goals too far in advance, like planning out the goals for January, February, and March at the start of the quarter.

I intentionally don't do this because I think you're much more likely to overperform, underperform, or deviate from your goals in some unexpected way than makes planning too far in advance kind of pointless.

Instead, I don't plan the next periods goals until the end of the previous period. So on Friday, I'll take some time to clean up my goals from that week and plan the goals for next week. At the end of the month, I set the goals for next month. At the end of the quarter, I set goals for the next quarter.

As I'm doing that, I might find that some goals no longer make sense, or need to be adjusted, at higher levels in the system. That's totally fine, and I think an important part of the process. You don't want to let yourself off easy from tough goals, but you also don't want to force yourself to keep pursuing something or some direction that no longer make sense.

Further Modifications

This is meant to be a flexible, adaptable system to however you like to set and track your goals.

One thing you might add is a longer term view, like five or ten year goals. Taylor Pearson uses a similar system, where he goes all the way up to 25 year goals.

You could add Life Goals, you could add a Habit tracker, you could go down to Hourly level tracking… go crazy. Airtable is pretty flexible for this kind of structured data, and I've been enjoying using it for this and my personal CRM.

Have fun with it, and let me know what modifications you come up with on Twitter.

If you need to streamline your team's operations, ensure that multiple teams in your org are working from a single source of truth, maintain a canonical inventory, or perform any other database?

So clearly, good database design is important when trying to build a database that works for you. But what does it actually mean for a database to be well-designed?

A well-designed database enforces data integrity

Data integrity refers to the overall accuracy, completeness, and consistency of the data in your database; a well-designed database maintains data integrity by implementing the processes and standards proposed during the design phase.

Data integrity includes three specific technical aspects of a relational database's structure:

• Entity integrity (or table-level integrity) ensures that a table has no duplicate records, and that the values of the table's primary keys are all unique and not null.
• Domain integrity (or field-level integrity) ensures that the purpose of every field is clear and identifiable, and that the values in each field are valid, consistent, and accurate.
• Referential integrity (or relationship-level integrity) ensures that the relationships between pairs of tables are sound, so that the records in the tables are synchronized whenever data is entered into, updated in, or deleted from either table.

A well-designed database enforces relevant business rules

Every organization does its work a little differently, and as such, each organization has its own unique requirements for its data, also known as business rules. Some hypothetical examples might be: a video production company requires that the duration timestamps for its video files be stored in milliseconds; a consumer brand requires that each product in its catalog be assigned a unique eight-character alphanumeric code; a university requires that its students sign up for no more than six classes per semester.

Ideally your team's database should be able to enforce your unique business rules; this will ensure that the data coming into your base is both accurate and useful. For example, if the university in the previous example forgot to account for their business rules when building their database, a student might try to sign up for 20 classes in a single semester—creating a mess for a database administrator to clean up later.

How to design your relational database, step by step

If this all sounds unfamiliar or overwhelming, don't worry—there is a systematic process you can follow that will ensure your relational database follows good design principles, is well-suited to your organization's needs, and avoids common pitfalls.

Step 1: define your purpose and objectives

Before beginning your database design journey, it's worth taking a step back and answering a very important question: 'Why am I making this database?' Are you making this database in order to manage business transactions? To store information? To solve a particular organizational problem? Whatever the case, it's worth taking the time to identify the intended purpose of the database you'll be creating.

You may even wish to work together with managers, leadership, and end users to jointly write out a mission statement for your database, like: 'The purpose of the Mingei International Museum database is to maintain the data for our art collection,' or 'Zenbooth's database will store all of the data for our manufacturing resource planning.'

Additionally, you should define the objectives that the end users of the database will have: which specific tasks will the end users need to perform in order to accomplish their work? Developing an explicit list of objectives—like 'Know the status and location of each of the pieces of art in our collection at all times,' 'Produce monthly reports on customer sales,' or 'Maintain complete records for each of our clients'—will help you determine an appropriate structure for your database as you work through this design process.

Step 2: analyze data requirements

Before you begin designing your database, you'll need to analyze your organization's data requirements. This might sound intimidating, but all it means is that you'll be assessing how your team currently does its work, and identifying what kind of data is most important to that work. You can do this by closely examining existing processes and by interviewing team members—both management and end users. Some questions to ask as you conduct your research:

• How is your organization currently collecting data? Are you using spreadsheets? Paper templates? Another database? Whichever of these methods you're using, find the most complete samples of work that you can, and look through them to find as many different attributes as you can. For example, your editorial calendar might currently be living in a spreadsheet, and have columns for 'Author,' 'Due Date,' 'Editor,' and so on.
• How is your organization currently presenting data? What kinds of reports does your organization use? PDFs? Slide decks? Web pages? Carefully examine any types of presentations that incorporate data from your current data collection methods and use them to identify potential fields.
• How are your team members currently using data? The best way to determine the answers to this question is by talking to team members—both management and end users—to identify their current data use patterns as well as any gaps in the current system. You can ask questions like, 'What types of data are you currently using?' and have them review the samples you collected. Importantly, these interviews can also illuminate plans for the future growth of the organization, which will give you some insight into future information requirements.

Step 3: create a list of entities and a list of attributes

After settling on your organization's purpose and objectives, and analyzing your data requirements, the next steps are to extract a list of entities and a list of attributes from the body of research you've compiled. In the context of relational databases, an entity is an object, person, place, event, or idea—like 'clients,' 'products,' 'projects,' or 'sales reps.' Attributes are the defining characteristics of those entities, like 'name,' 'quantity,' 'address,' 'phone number,' or 'genre.' One way you can think about this is that entities are like nouns, and attributes are like the adjectives that describe those nouns.

Start by picking out entities from your research and putting them on a list. These entities will eventually serve as a guide to help you define your tables later on in the design process, but they will also help you identify the attributes necessary to create your list of fields. For example, if you were developing a talent database for a record label, your entities list might look something like this:

• Artist
• Agent
• Venue
• Gigs
• etc.

Next, create a separate list containing the relevant attributes for each of the entities you've identified, as well as any other attributes that might have come up during your research. These attributes will define the fields for your tables. Again, for the talent database example, your attributes list might look something like this:

• Artist Name
• Artist Phone Number
• Agent Name
• Agent Phone Number
• Agent Email Address
• Venue Name
• Venue Address
• Gig Dates
• etc.

Once you've collected a preliminary list of attributes, you should go through and refine them to make sure that they accurately represent your organization's informational needs.

Tips:

• If multiple attributes have different names but actually represent the same concept, deduplicate them so there's only one. For example, if you have both 'Product No.' and 'Product Number' on your list, you should remove one of them.
• If multiple attributes have similar names but actually represent different concepts, rename the attributes to be more specific. For example, you could rename two different 'Name' attributes into the more specific 'Artist Name' and 'Venue Name.'

After refining your lists, it's a good idea to review these lists that you've compiled with some of the team members you interviewed to confirm that you've accounted for every necessary type of data. Be sure to take their feedback into consideration and further refine your lists as appropriate.

Step 4: model the tables and fields

After creating your lists of entities and attributes, your task is to use those lists to design the structure of your relational database. Your list of entities will become the different tables in your base, and the list of attributes will become the fields for these tables.

Take your lists and assign each of the attributes to your tables. For example, after we finish assigning our listed attributes to our new tables, our talent management database-in-planning might look something like this:

Next, you need to pick an appropriate primary key field for each table. A primary key is a major component of ensuring data integrity, as it uniquely identifies each record within a table and is used to establish relationships between different tables.

Each table's primary key field should meet the following criteria:

• It must contain unique values. This will prevent you from creating duplicate records within a table.
• It cannot contain null values. A null value is the absence of a value, and as such, you cannot use a null value to identify a record.
• It should not be a value that will need to be modified often. Ideally, primary key values will remain relatively static over time and only be changed under rare circumstances.
• It should not be sensitive personal information. Social security numbers, passwords, personal health information (PHI) and other sensitive data may be unique, but should not be used as primary keys, as doing so makes it much harder to keep this data appropriately secured in a single location.
• Ideally, it uses the table name as part of its own name. While not strictly necessary, having the table name in the primary key field name can make it easier to identify the table from which the primary key field originated. For example, 'Employee Name' would be obviously identifiable as coming from the 'Employees' table.

It might be possible that your preliminary list of fields for a given table does not contain one single field that meets all these criteria. However, you may be able to combine two or more fields to create a separate, unique field which does meet all these criteria. For example, you could combine the values in a 'Given Name' field and a 'Surname' field to create a third, calculated 'Full Name' field using a concatenation formula.

In the event that this strategy still doesn't work for your purposes, you can always manufacture a new field designated specifically for unique identification codes to serve as your primary key field. Fields like 'Product ID' or 'Sales Invoice Number' are often created for this purpose.

Let's return to our talent management database example. For the 'Artists' table, the 'Artist name' field is already a pretty good candidate for the primary key, as it's pretty unlikely that your record label will sign two artists with the same name. We can also pick 'Venue name' as the primary key for the 'Venues' table. For the other tables, however, it would probably be better to make new fields that concatenate values from existing fields. In the 'Agents' table, we might make a new field—'Agent full name'—that concatenates the values of the 'Agent given name' and 'Agent surname' fields. For the 'Gigs' table, an artist could perform at the same venue on multiple occasions, so we should make a new field that gives a unique name to the specific combination of an artist at a venue on a specific date. You could potentially concatenate the name of the artist, the venue, and the date to create values like '2 Linkz at the Gotham City Metro Club, 02/13/2019,' but that can get long and unwieldy fast. Alternatively, you could try creating a new field—'Gig code'—with unique alphanumeric code values (like 'E0023'). Whichever approach you take is up to you and your team's specific needs.

Step 5: establish table relationships

Once you've identified your tables, fields, and primary key fields, you can start the process of linking them all together. Using your knowledge gained from your prior research and conversations with other team members, you can make a preliminary attempt to define the logical relationships between your different tables.

Relationships between tables are created by linking together primary key fields and foreign key fields. A foreign key is a field in one table that references the primary key of another table. For example, if you were designing a sales pipeline database, your 'Deals' table might contain a 'Sales Rep' foreign key field, which would link to your 'Sales Reps' table; if you were designing a content calendar database, your 'Pieces' table might contain an 'Editor' foreign key field and an 'Author' foreign key field, both of which would link to your 'Staff' table.

To start defining the relationships between your different tables, identify the potential foreign key fields. In an ideal relational database, foreign key fields are the only fields that should ever be duplicated, so if you identify any fields that appear in multiple tables, those are likely candidates for foreign key fields.

Returning to our talent agency example, we can go through our lists of fields per table and identify the fields that share names/concepts with the primary key fields of other tables:

There are three types of relationships between tables:

• One-to-one relationships, in which a record in one table is related to one and only one record in another table. An example of this might be an IT team's asset tracking database with an 'Employees' table and a 'Computers' table: each employee only possesses one company-owned computer, and each company-owned computer is possessed by only one employee. (Note that one-to-one relationships are relatively uncommon.)
• One-to-many relationships, in which a record in one table can be related to one or more records in another table. An example of this might be a project tracker database which contains a 'Projects' table and a 'Tasks' table: each project has multiple associated tasks, but each task is only associated with one project.
• Many-to-many relationships, in which one or more records in one table can be related to one or more records in another table. An example of this might be an inventory of books, which contains a 'Titles' table and an 'Authors' table: each title will have been written by one or more authors, and each author can have written one or more books.

Being able to identify the different types of relationships is helpful for modeling your organization's business rules. For example, if you specifically define a relationship as one-to-many, you can enforce a rule that the records on the 'many' side of the relationship can, indeed, only ever be linked to one record in the other table. (More on this in the next step.)

One activity that can be very helpful for visualizing how your tables will relate to each other is creating an entity-relationship diagram, or an ER diagram. An ER diagram is a kind of chart that uses shapes to represent your tables and lines to represent the relationships between your tables.

You might be wondering why you would want to go through the effort of establishing the relationships between these tables. The main reason is that the table relationships actually allow you to make logical connections between pairs of tables, which in turn allows you to draw data from multiple tables simultaneously. Being able to draw data from multiple tables simultaneously means that you can make your tables more efficient and minimize redundant data. If you construct your table relationships appropriately, you can see whatever data you need to see from any table, at any time, but you'll only ever need to enter it or modify it in a single location.

To better understand how this might work in practice, let's return once again to our talent agency example. Suppose you wanted to be able to see at a glance how much revenue each artist has generated in total across all their gigs. Because you've already established a relationship between the 'Gigs' and the 'Artists' table, you can use that relationship to look up data from all the relevant gig records per artist.

To do this, you can create a new computed field in the 'Artists' table—'Total gig revenue'—that sums the total value of 'Revenue generated per gig' for all linked records in the 'Gigs' table per artist. A computed field is a special kind of field that automatically generates a value using one or more values from another field in the database. Because the computed field updates automatically, if you ever edit a value in the 'Revenue generated per gig' field or add any new gig records for a particular artist, the 'Total gig revenue' field will also update automatically.

You can even take this one step further: if you wanted to see how much revenue each agent has generated in total through all the artists they manage, then you could use the established relationship between the 'Artists' and the 'Agents' table and create a new computed field in the 'Agents' table—'Artists' total gig revenue'—that sums the total value of 'Total gig revenue' for all linked records in the 'Artists' table per agent. Since this new computed field in the 'Agents' table is connected to the 'Gigs' table via the 'Artists' table, it will also be updated automatically if the values in the 'Gigs' table change, even though there is no direct relationship between the 'Gigs' and 'Agents' tables.

Step 6: establish business rules

After fully establishing the overall structure of your database, it's time to incorporate your organization's unique business rules into your database design. Because business rules are so closely tied to the specific ways in which your organization does its work, your most valuable resource will be, once again, managers and end users. Consulting with them can provide invaluable insight into which constraints will be the most impactful for your workflows.

Generally speaking, there are two main kinds of business rules. Field-specific business rules refer to constraints placed on specific fields. Some examples of field-specific business rules might be 'Dates on our product order invoices must be displayed in the ISO format ‘2020-12-22,'' 'Email addresses stored in the employee directory must be valid email addresses,' or 'The only valid values that can be selected for this status field are ‘To do,' ‘Doing,' and ‘Done.''

Relationship-specific business rules, which we briefly touched on earlier, refer to constraints placed on table relationships. Some examples of relationship-specific business rules might be 'Each project in our video production tracker must be linked to one or more fact-checkers,' or 'Each line item in a customer's order must be linked to one and only one product.'

Best Air Table Examples Pdf

The most thorough method of identifying and implementing your field-specific business rules is to systematically review each field within each table to determine which business rules apply to that field. Every field will have some relevant business rules, even if those rules are as general as 'Every value in the ‘Employee first name' field should be a string composed of letters.' In a similar fashion, you can systematically review each of the relationships in your proposed database structure and assess whether or not they require any relationship-specific business rules.

In the future, you will probably need to change your existing business rules or add new business rules. For example, your team might decide that 'Canceled' should be a valid potential value for a task status field that currently includes only 'To do,' 'Doing,' and 'Done' as options. Fortunately, if you have followed the previous steps and set up a robust underlying database structure, it should be relatively easy to adjust your field- and relationship-specific business rules down the road without having to restructure your entire database.

Step 7: check your work

You're almost done with the database design process—all you need to do is perform one final review of your database. A few questions to ask yourself as you look over every table, field, and relationship:

• Does every type of entity have its own dedicated table?
• Are there any tables that might need to be consolidated, or, conversely, decomposed into multiple tables?
• Are there any duplicate fields in my database that are not foreign keys?
• Do each of my fields have defined specifications that match our organization's business rules?
• Do the relationships between my tables make sense?

Airtable Blocks

If everything looks good to you, you should run the final product past the end users and managers who will be interacting with the database. If they're satisfied with the end result, then rejoice! Be proud of your new, structurally sound database.