Person: To prepare yourself for writing LookML code, there are some key terms and overall project structure that you need to know. Let's begin with an easy one. What does the ML in LookML stand for? LookML stands for Looker Modeling Language. It's Looker's proprietary language that establishes an abstraction layer for SQL. Developers use LookML to tell Looker what data to use from the connected database and how it should interpret that data. Specifically, LookML acts as the modeling between the connected SQL database and your business users. Looker uses the LookML code written by developers to define how business users interact with a connected database and to construct SQL queries against that particular database. Developers use LookML to define many items from the connected SQL database, including data attributes called dimensions, aggregates of dimensions called measures, data relationships such as how to join tables and custom tables and fields. A key concept of LookML to remember is if it's possible in your SQL dialect, it should be possible in Looker. If you can go to your database console and handwrite a SELECT statement that does something in the database, you can also code LookML that Looker can use to accomplish the same task. For full comprehension of the key LookML terms, developers need to understand where each object fits into the overall hierarchy of a LookML project. The highest level is the LookML project itself, which is a library of self-contained LookML code. Because Looker uses Git for version control, a best practice is for each project to map one-to-one with a dedicated Git repository. A project is essentially a library of code for a specific data source or database connection and contains one or more data models. You can think of each project as a semi-independent or mini instance of Looker, and each project should map one-to-one to a Git repository for version control. Data that cannot be joined together should be separated into different projects because there's no relation to be made across the data. The next level in the hierarchy are models. As previously mentioned, a LookML project is composed of one or more models. A model specifies a database connection and the data views that utilize that connection. Specifically, a model file is used to define the database connection, the view files that are accessible to this model, the Explores, which are prejoined views and their join logic. Next on the hierarchy are Explores, which are sets of prejoined views organized by business area defined within the model files. For example, you might create a model file containing multiple Explores pertaining to customer purchases. Explores are the central component of Looker that allow business and data analysts to conduct self-serve data exploration, analysis and visualization. Within a model file, developers define Explores that join one or more views together to target specific questions that business users may have. Business users then use the predefined Explores to run queries and create reports and visualizations to answer their questions. So you can think of an Explore as a predefined set of tables that would frequently be joined for business inquiries and use cases. Next the views that are joined in the Explores represent the underlying database tables. Views are the building blocks of Explores used by business users. Within view files, developers can define the dimension or data attributes and measures or aggregations of attributes to provide business users in the Explore interface. The view names that are joined to create an Explore are also the headers that business users see in the Explore. For example, in an Explore called order items, business users may see the users' view, which contains dimensions on users such as their age and city of residence and measures such as their total purchases. Last but not least on the hierarchy are the dimensions and measures defined in the view files. Dimensions are data attributes and represent the field or column of a database table. When the view files are generated from a table by Looker, dimensions are automatically created for any columns that already exist within your database tables. You can also create additional dimensions that would serve as logical representations of table columns. All dimensions appear in the SELECT and GROUP BY clause of a SQL statement that is generated by Looker based on the business user's selections in the Explore. Measures are aggregates of dimensions and do not live explicitly in your database tables. They must be created using LookML. They aggregate dimensions into values like sums or counts. Note that they do not appear in the GROUP BY statement of the SQL generated by Looker. Instead, they depend on dimensions to determine that grouping, so they appear as aggregate functions in the SELECT statement of the SQL query. To recap, a LookML project is a library of code that models a data source and should map one-to-one to a Git repository for version control. Projects contain model files, which define the Explores that should be packaged together, how those Explores work and which views are joined in which Explores. View files describe database tables or logical representations of them and are joined together to define Explores in the model files. Views are then accessed by business users through the Explore to query data and create reports and visualizations. Dimensions and measures are defined within view files. Dimensions are attributes of data and represent fields or columns in the database tables, while measures are aggregates of dimensions such as a count or a sum. After this introduction to the LookML key terms and hierarchy, you're now ready to start exploring your organization's Looker instance as a LookML developer.
