Designing a User Database for Card Access Systems

How long does it usually take for you to unpack your clothes and organize them after you move? If you’re anything like me, they might slowly move from your suitcases and boxes to a dresser over a healthy span of weeks. In the interim, I have to develop an internal logic of where, in all the clutter, certain clothes are located: dress shirts in the box at the foot of the bed, socks and underwear tucked in front of the dresser. Even my logic fails me sometimes, though, and I’m left spending sometimes (very) precious minutes looking for something which could have already been in an easy-to-locate drawer. When I’m working through my unpacking, I always take into account a few factors: how big my closet space is, what all needs to be hung-up, and how often I need to use any specific articles of clothing. To my chagrin, sometimes you need to make additions or re-organize your clothes in order to make up for low closet space. Whatever form my clothing storage takes, I am always categorizing them for the sake of my own efficiency.

As painful as unpacking is, the skill has been extremely helpful in understanding the priorities for one of my recent design projects: designing a user database for a card access security system. Searching a database in security access control is significantly more complicated than finding a pair of shorts, but the logic is still there: have a system in place where the organization is easy to see and easier still to access quickly. My primary concerns are still usability, security, and storage. I didn’t focus on the way my pants were stored— I focused on building a database for a card access system that is easy and quick to access.

This process becomes more challenging when you do not properly consider the need for a speedy and stable process between user detection and validation. Without an efficient database, it would be impossible to make the system keep up with the speed that users will access it. Two key concerns—ensuring the routing of data signals comply with best PCB design practice and has a strong organization of information—are paramount to the success of a user database card access system.

Build for the Size

A user database can take many sizes, and the larger it becomes the more the system needs to do in order to access its user information. In order to make sure that your database works up to your expectations, here are three processes to keep in mind:

• Identification: Allocating enough space for user identification is necessary for proper database management. The priority in “user database” is the user, after all. In order to store individual identities, one must create a group of datasets for the token users. Once you have a sample, then you can design the rest of the database around the size and parameters of individual users so as to ensure that you are not overstuffing a page or slowing down the system.

• Searching, Sorting, and Validation: The goal for a searching and sorting system is to maximize speed. If I spent long enough, I’m sure I could find anything in the dozens of boxes in and around my closet, but the fact of the matter is that I don’t want to spend that much time looking. No user will want to spend longer than a few moments when they’re swiping their card to access something. In order to optimize speed, you need a direct process of creating user tokens, sorting them into their respective pages, and having a systemic organizational order for the system to predictably find them.

• Memory Storage: You must choose the appropriate memory chip for the card in order to enable a proper identification token retrieval by the card access system. Depending on the card chosen, this can affect the speed of the process as well as the reliability of the communication signals.

Anticipate Memory Mapping and Pagination

In a security access control system, users are validated based on the card identification number or the personal identification number. These are often described as a “token.” However, the validation requires more than validating the token itself. There are various parameters that need to be verified before a user can be granted access. For example, such parameters may include the access level given to a specific area, the allowable access time, and the blacklist code. To further define the user token, you should be sure to create groups of datasets by their functionality. Such datasets may include user records, access level, access time, and holiday exceptions. After making an individual record, one determines the individual byte size.

It’s important that you have an idea of the data flow the moment a user presents his identification token. In this case, all validation starts with the user record before ensuring that other conditions are met. As the system needs to support many thousands of users, the user records need to be organized in pages. For example, page 1 might store 1,000 tokens of user data with token IDs that start with 001 while page 56 stores another thousand token IDs with the 056 prefix. You might not have all of your shirts labeled, but they’re certainly still individually identified: old gray t-shirt, white shirt, blue-shirt-from-vacation, etc. By keeping these mental notes, you make it easier to find them in the future.

Set Your Searching and Sorting Algorithm

To quickly search and compare a user token against the database, the user record needs to be stored and sorted in a definable, organized manner. In actual applications, the database is empty from the start and only populated when new users are registered. Each of the user records must be placed in the designated memory page based on their token ID. After every new record insertion, the page must be sorted so that each record is arranged in an ascending manner.

A direct mapping from the token ID to the memory address is not possible as the user records are only inserted when registered. Sequential comparison, where the token ID is matched against one record before moving on to the next, is an inefficient approach—if comparing a record takes 1ms, it would take 900ms for 900 matching attempts. If the whole process takes more than 1 second, it’s not good enough.

The best way to validate a record in a sorted database is through binary search algorithm. This is where the array of record is divided into half and the token ID is compared against one of the halves. If the result is negative, the same process is repeated in the other half until a positive match is achieved. With binary search algorithm, the time taken to validate records is reduced exponentially.

Select Your Memory Chip

Any design concept is only as good as its implementation. When it comes to database design on an embedded system, memory chips are crucial to ensure not only the capacity requirements are met but also minimal latency in writing and storing the records. In my design, flash is the natural choice to store this vast amount of information. Previously, high capacity flash required parallel bus connections. Today, serial flash offers similar high capacity storage and in various flavors for your specialized memory storage needs.

While I don’t have any advice to make unpacking anymore fun, you can certainly make it easier on yourself by following the same tips as for designing a user database. When you need to access an easy-to-use PCB layout tool that includes everything needed to build high-quality manufacturable circuit boards, look no further than CircuitMaker. In addition to easy-to-use PCB design software, all CircuitMaker users have access to a personal workspace on the Altium 365 platform. You can upload and store your design data in the cloud, and you can easily view your projects via your web browser in a secure platform.

Start using CircuitMaker today and stay tuned for the new CircuitMaker Pro from Altium.