Tuesday 24 December 2013

MS Access Functions | Domain Functions

MS Access supports several functions for manipulation of data. One such set of functions that are available throughout Access maybe it in Queries or VBA are the Domain functions.  

What are Domain Functions?

Domain Functions are some inbuilt functions that can access the Data in Tables. In simple terms Domain functions are simplified Queries. If you are ever in a position to need to Count the number of Customer in the table who has their first name as 'Paul', you start typing..
    
    SELECT Count(FirstName) As CountOfFirstName 
    FROM Customers
    WHERE FirstName = 'Paul';

So if you are someone who is very lazy (like me !) or you have very limited knowledge of writing Queries or even if you think writing Queries is a bore, then you are in luck. Someone thought to just do this is a simpler way, just tell the compiler what you need, where to look and it gives you a result. That is the discovery of the Domain functions. 

Identifying & understanding a Domain function

In general Domain functions start with the letter 'D'. There are about 8 Domain functions.
  • SELECT Domain functions
    • DFirst 
    • DLast
    • DLookup
  • AGGREGATE Domain functions
    • DAvg 
    • DCount
    • DMax
    • DMin 
    • DSum
As you can see the Domain functions can be categorized as SELECT and AGGREGATE. SELECT can return Data from a Domain, where AGGREGATE returns the value of multiple records combined together.The beauty of Domain function is that it can work on both Tables and Queries. 

Things to know !

  1. All parameters are treated as Strings. So make sure you enclose them in Double Quotes.
  2. A Domain function can return only one Value even if the records returned are more than one.
  3. A Domain function can return a Null value, if the condition is not met. So be prepared to capture that scenario.
  4. Domain functions can be heavy, so best to limit its usage.
  5. The criteria should be evaluated to a String, based on the Data type of the field the condition would vary. Look at the common usage syntax for more information.

Anatomy of a Domain function

All domain function can be broken down into three parts
  • expression - the field name where the function needs to look at
  • domain - name of the table/query where the function needs to be applied
  • criteria - (Optional) if you are looking for something in specific, then you add it here.
So as you can construct a Domain function as,

    DFunctionName("expression", "domain", "criteria")

For the example we are dealing with, the function we would use be Count.

    DCount("*", "Customers", "FirstName = 'Paul'")

If you have seen the above example, I have used the * as the Column/Field name, this is because, specifying a particular column in a Count function would slow down the compiler. To be efficient using a * would be faster. 


Common Usage Syntax

The first example of every Data Type would be written basically for normal use, the second uses Form reference and how to concatenate them into the Criteria.

For Inbuilt constants/Numeric,
    DLookup("FirstName", "Customers", "ActiveCustomer = True") 
    DFirst("LastName", "Customers", "CustID = " & Me.IDTxtBox)

For Strings,
    DCount("*", "Customers", "FirstName = 'Paul'")
    DAvg("annualPay", "Customers", "City = '" & Me.cityTxtBox & "'")

For Dates,
    DSum("QuantityOrdered", "Orders", "dateOrdered = #12/01/2013#")
    DMax("QuantityOrdered", "Orders", "dateOrdered = " & _
          Format(Me.dateTxtBox, "\#mm\/dd\/yyyy\#"))

Saturday 7 December 2013

Fundamentals of Database Design

Hello, Welcome to Paul's learning curve! It's been quite a while since I had written a Blog. Now I promise to keep this consistent.

So I am here to help you out with some of the basic and simple tips and tricks with Access, that could make your life a little bit easier! The topic today is essential, and fundamental for any Database structure! This is available on YouTube !

As we have covered in my first post, JET is a Relational Database Management System. This means that the Database is dependent purely on Relationship Models. 





Throughout this post I will be using a simple example of Student information, to help you understand the fundamental principles. Let’s begin!

Rule - 1: Every row in a table must be unique.
    What it technically means by is that, consider a class of students, it is impossible to have two students who are exactly the same, to identify each student we use a unique identifiers in this case a Student ID, this is called the 'Primary Key'. The functionality of this Key is that it will not allow you to enter a record which will be a duplicate. Simple!

Rule - 2: Data should be "Atomic"
    Data in its raw form might be clunky, in a Relational DB you should not be condensing information in one single column. Simple examples would be Address of a Student. The address would contain several bits of information, House number, City, County and Post Code. All these information are by itself separate and needs to be in their own columns as such.

Rule - 3 : Data should be single valued
    Similar to Rule 2; although a bit different, let me explain with an example. If a student is taking up 3 major subjects, These subjects should not go in one column "Subjects taken" and store all the information in that column : Maths, Science, English. Instead they should go in a new table linking to every single student record, thus creating a relationship between the two tables.
   
    Why you may ask? Well the reason is quiet obvious, if you create three columns Main subject 1, Main Subject 2, Main subject 3 and then you need to collect other information regarding the subject maybe course start date. If you keep adding new columns there will be three additional columns each for one subject, the more information you need the more columns you will end up adding. So this stage you create a new table, tbl_courseInfo specific to courses. As the DB structure grows you will understand that DB does not contain just one table, but several tables broken down and combined together forming the information we require.

Rule - 4: Data Redundancy
    So as the words plainly mean, never have the same information in multiple tables, this will only cause trouble of what you are referring to. The simple example would be from Rule 3, all you need to link the two tables together is the ID, the Name and address can be obtained by simply JOINING them in Queries. There is no need to save the information on to the new table.

Rule - 5: Avoid calculations/dependent values
    This is a major and very important aspect. Example could be Grading system. You should not create a Column in the table for this, if you need grades you calculate when and where required using Queries. Never store such calculations.

So the above five rules, simply dictate how a DB should be designed. This is the tip of the iceberg, there are several more to be discovered, Normalization being another huge topic. There should be plenty of tutorials available online for you to learn this.

So let’s finally recap: Five fundamental principles to a DB Design:

  • Unique Records
  • Atomic Data
  • Single Valued
  • Data Redundancy
  • Dependent data.
If you follow this simple 5 step rule, I am sure you will not be going wrong in any aspect of your design. If in doubt make sure you ask for help !