How to correctly use "Anonymous" information on a database (1 Viewer)

DBApprentice

On Error GoTo AWF *****:
Local time
Today, 06:31
Joined
Dec 24, 2018
Messages
150
Hello again!

I have a pretty simple question (For you, of course, too complex for me):

Considering you have to record information (Like a complaint) coming from people that wants to be anonymous what would be the best approach when comes to database design?

First I considered creating a "person" named UNKNOWN. But later I tought I could accepct NULL values on the person´s name, but now I am on the middle of building the forms to see the complaints and the blank textbox are looking very odd... So I decided to add a checkbox named "UNKNOWN" and trhow some code for enabling/disabling controls, err... too much trouble for a simple task.

Now I am thinking maybe I could add a checkbox to the original table if a person remains anonymous I will fill it. :confused:

What would you guys do? If a table will address anonymous people should I remain with Nulls or move to "UNKNOW" solution. If I am not even right about these approaches please be my guest to propose your solution.

PS: Please consider this is my very first project in Access and I am still settling DB Design in my mind.
 
Last edited:

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 04:31
Joined
Feb 28, 2001
Messages
27,167
There are schools of thought on this, but to avoid problems with relational integrity, you might do best to have an "Anonymous" person defined and allow that to be selected. OR allow the user to NOT enter their own name. Then, before you save the record, check for that name box to be empty/null/blank (whichever mode of testing works in that context) and select the "Anonymous" user automatically.

This answer depends a little bit on whether the users who would use it have to be logged in to the database via a table of valid users or whether you allow "strangers" to file complaints. If your users have to be logged in, then do this with a pre-defined anonymous user and have a "radio button" control on your form that by default says "Use my name" but that can be switched to say "File as Anonymous"

And it ALSO raises another question: If the users have to be logged in to the database or otherwise known to you ahead of time, WHY would they wish to file an anonymous complaint?

And here is another comment: Give them incentive to NOT be anonymous by providing a pop-up yes/no message box that says "If you remain anonymous we cannot give you feedback if/when we address this issue. Do you still wish to be anonymous?"

Just some food for thought.
 

DBApprentice

On Error GoTo AWF *****:
Local time
Today, 06:31
Joined
Dec 24, 2018
Messages
150
There are schools of thought on this, but to avoid problems with relational integrity, you might do best to have an "Anonymous" person defined and allow that to be selected. OR allow the user to NOT enter their own name. Then, before you save the record, check for that name box to be empty/null/blank (whichever mode of testing works in that context) and select the "Anonymous" user automatically.
...

I guess I will go with that solution, in fact it was my first thought but I wasn´t sure if that would create problems. Turns the other option is troublesome and that saying is always coming back to strike me: the simpler the better!

...
And it ALSO raises another question: If the users have to be logged in to the database or otherwise known to you ahead of time, WHY would they wish to file an anonymous complaint?

And here is another comment: Give them incentive to NOT be anonymous by providing a pop-up yes/no message box that says "If you remain anonymous we cannot give you feedback if/when we address this issue. Do you still wish to be anonymous?"

Just some food for thought.

I appreciate your comments, certainly I have not made a very well explanation of my database and it is indeed confusing.

The DB will track safety observation cards written by people working on a place, they can state their names and we can track them down, but they can choose to remain anonymous. Doing so will also prevent them from being awarded later, but it also avoid exposing them to the head of department.

As always your insights and food for toughts are good to keep for any future application and I will save them for sure!

Thanks!
 

CJ_London

Super Moderator
Staff member
Local time
Today, 10:31
Joined
Feb 19, 2013
Messages
16,607
not sure I can answer the question of a 'best way'. A lot will depend on your organisations privacy policies

you can use the format property on a control to display something instead of null - e.g. for strings

@;"Unknown"
 

DBApprentice

On Error GoTo AWF *****:
Local time
Today, 06:31
Joined
Dec 24, 2018
Messages
150
you can use the format property on a control to display something instead of null - e.g. for strings
@;"Unknown"

I was indeed not clear on my post, I am sorry for that!:eek:

When an operator is transcripting a card into the database (Yes, it´s 2019 and we are still transcripting instead of offering an online form for that matter), he will will have to assign the card to a person (Observer) but if the person wrote the card and did not inform his name then the operator will have to include the card anyway on the database.

My question was based on this "anonymous" person´s card:

Should I use a value "anonymous" on the observer table or should I leave it as null?:confused:
 

CJ_London

Super Moderator
Staff member
Local time
Today, 10:31
Joined
Feb 19, 2013
Messages
16,607
the operator will have to include the card anyway on the database
I understand that. The table that is being populated presumably has a primary key field? and you can set up a timestamp field as well so you know when a record was created. Perhaps you don't even bother to enter a name? why does it matter? Presumably it is the observation that matters? If names aren't a requirement for successful analysis, how does requiring it to be entered help?

If you do include a name then I would also expect the name field to be indexed. If a name is not provided then personally I would leave the name field blank and use the format I was suggesting. Why? because you can set the index to ignore nulls so it will be faster. Yes you can populate it with 'Anonymous' or something else, but that will just slow the index down - and mean the operator has extra work to do to type in 'Anonymous' - and may spell it differently by accident.

Why does it slow the index down? - see this link about indexing https://www.access-programmers.co.uk/forums/showpost.php?p=1516326&postcount=1

However if you don't have that many records, indexing won't make that much difference but it is about applying proper rules around database design.
 

Micron

AWF VIP
Local time
Today, 05:31
Joined
Oct 20, 2018
Messages
3,478
You know what would avoid all of this? Having a culture where the health and safety of your fellow employee is your business, and outside of flagrant violations coupled with "get out of my face" attitudes, there's no repercussions for approaching anyone and none for being "counseled" by your co-worker. You might think that's not possible, but I can tell you that it is. It just takes time to get there. The idea of anonymity so that you can "rat" on your fellow employee for violations is, sadly, archaic. I guess I was just fortunate to work in a place that had a culture like I describe. Don't think for one minute that it happens over night. What I saw took about 10 years and a lot of corporate effort to make it happen.
Soapbox emoji here (if I could).
 

DBApprentice

On Error GoTo AWF *****:
Local time
Today, 06:31
Joined
Dec 24, 2018
Messages
150
You know what would avoid all of this? Having a culture where the health and safety of your fellow employee is your business, and outside of flagrant violations coupled with "get out of my face" attitudes, there's no repercussions for approaching anyone and none for being "counseled" by your co-worker. You might think that's not possible, but I can tell you that it is. It just takes time to get there. The idea of anonymity so that you can "rat" on your fellow employee for violations is, sadly, archaic. I guess I was just fortunate to work in a place that had a culture like I describe. Don't think for one minute that it happens over night. What I saw took about 10 years and a lot of corporate effort to make it happen.
Soapbox emoji here (if I could).

I guess that´s would raise an error on my entire project:
Code:
"Error 6: OVERFLOW"
. I totally agree with you and I had the pleasure of working in a major energy company in the global market and it was exactly like you described: took time and efforts to get there.

Despite of being out of the scope of the forum, rest assured the head of departments here don´t have that culture of vengeance. However we have 150 persons on a oil drillship that spot issues every hour that concerns safety of the entire crew and some of them will be just too affraid to stand up and tell his name. That´s why we have to deploy this program (In fact, it´s mandatory by the National Petroleum Authority in Brazil), so that people can report issues and we can track it down and provide a feedback to the person later and also to the client or ANP.

It´s people´s behavior and mindset, they are always affraid of being fired or being damaged somehow if he reports he saw a welder using a blow torch near a diesel tank, or to report that the Superintendent decided to breach a safety barrier during a 5000psi test on the lines just to test if someone would stop him. All these things has potential to kill or explode this vessel but they won´t stand up and be accountable if they have to id themselves.

You can try all day long and it won´t change!

UNLESS throwing an award to the program, for instance I worked with a vessel where this safety cards program would award weekly the best observation card with an iPod Touch, and the best card of the month would win a brand new iPad. Boy, we had 150 cards every single day, all named! Even some cases were blatantly staged - it would be called "Drillywood" these days - by some employees just to make an awarded safety card. Some hotshot company manager had even thrown MacBooks or iPhones to the bargain to see the program engagement grow.:eek:

I never figured out why you should need an award to step up if one could easily fire you after you get that prize... beyound my paygrade and inteligency it is.
 
Last edited:

DBApprentice

On Error GoTo AWF *****:
Local time
Today, 06:31
Joined
Dec 24, 2018
Messages
150
I understand that. The table that is being populated presumably has a primary key field? and you can set up a timestamp field as well so you know when a record was created. Perhaps you don't even bother to enter a name? why does it matter? Presumably it is the observation that matters? If names aren't a requirement for successful analysis, how does requiring it to be entered help?

Excuse me, CJ_London, but I am not sure why I feel a little sarcasm coming from you here... Pardon me if I am wrong.

We are talking about a real business case that is in place for years and they are trying to have a small app in Access to handle that. They don´t require it to be fancy or scalable, just provide fast data-entry and handle the queries they will run along with a couple of reports.

Answering your questions, the names will be important to track how many cards a person has done, it will also be used to award the person who made the card. However, the program already exists but they are being tracked on Excel for a while now and there are tons of anonymous cards that we have to register on the tracking app/spreadsheet. The company can´t oblige the crew to id themselves if they don´t feel comfortable enough.

So I need to deal with this scenario and find out how to correctly address these tons of nameless cards on this application. In the Excel counterpart we had included a "UNKNOWN" person so that these cards would be registered.

If you do include a name then I would also expect the name field to be indexed. If a name is not provided then personally I would leave the name field blank and use the format I was suggesting. Why? because you can set the index to ignore nulls so it will be faster. Yes you can populate it with 'Anonymous' or something else, but that will just slow the index down - and mean the operator has extra work to do to type in 'Anonymous' - and may spell it differently by accident.

Why does it slow the index down? - see this link about indexing https://www.access-programmers.co.uk/forums/showpost.php?p=1516326&postcount=1

However if you don't have that many records, indexing won't make that much difference but it is about applying proper rules around database design.

It should be around 14000 cards per year for two ships... not much...

So I must index the name field and leve them blank. I can put a "UNKOWN" checkbox on the form to disable the control and leave it blank. Of course other validations will be done at form-level.

Is that a good approach?

Thanks!
 

Micron

AWF VIP
Local time
Today, 05:31
Joined
Oct 20, 2018
Messages
3,478
My suggestion would be to go back and review post 2 and seek any clarification around that, if necessary. Keep in mind how a name field, defaulting to Anon (or whatever) might cause issues when attempting to relate an unknown entity to anything else in the db as you will have a lot of unknowns that really represent any number of individuals. This means that while possibly having some uniqueness in life, there would be little to no uniqueness or relationship in the db. If there are no concerns, then I'd default to Anonymous via the form. A separate field to flag them as anonymous makes little sense to me.

No doubt you have or will encounter many times that it has been suggested to use a date field for flagging something as having a particular status. If no date, it isn't archived/obsolete/checked out/whatever. This has been suggested many times by accomplished db designers with apparently no objection to having many records with no date value (they are Null). Your name field with no name is no different. It comes down to whether or not you're happy with seeing nothing in the name field, or "anonymous". From a Quality Systems viewpoint, having no value is inconclusive - was the entry forgotten or not? Thus, it's better design to enforce a conscious entry, which means that a default value doesn't really fit that bill either. Just thought I'd throw that in for consideration, and thanks for the 'education' on the H&S aspect of what you're doing as I learned something new.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 10:31
Joined
Feb 19, 2013
Messages
16,607
Excuse me, CJ_London, but I am not sure why I feel a little sarcasm coming from you here... Pardon me if I am wrong.
No, not being sarcastic, just questioning why it matters which you answered in your responding post. It is the sort of question I would ask my clients because a significant element in designing a system is 'why' something needs to be done in a particular way.

I'm with Micron, each suggestion has its benefits so think about the how - how is the operator entering data and navigating the form - if purely by using the keyboard, do they need to stop occasionally to use the mouse to tick a checkbox? Or perhaps it's all checkboxes and the user is primarily using a mouse? How is the data going to be used - which defines what needs to be entered. etc.

the names will be important to track how many cards a person has done,
Not discussed but have you considered storing names in a separate table - in which case the user will be selecting from a combobox, not typing an name each time (i.e. user may only need to type in 3 or 4 chars to identify the persion). If you don't want to use a separate table use something like SELECT DISTINCT on the name field in your main table - so once a name has been entered, the combo will find it again. But my recommendation would be a separate table so if you have two John Smiths, you can identify them separately. But perhaps you have other ways of doing this.

whether or not you index a field is up to you - by the sound of it, it needs to be indexed - that would be my recommendation, but its your decision. With regards null v a value, I've given my reasons for using null, but again your decision. If leaving as null or a default, I don't see the need for a checkbox other than to imply 'yes it is null/default'
 

Users who are viewing this thread

Top Bottom