Is it ever okay to violate first normal form? - sql

Question

I have an Access database that will be required to present data with several one-to-many relationships on one row (e.g., it would list items as "a, b, e, f", and I would have multiple columns like that). I know it's a bad idea to store data that way as well, but considering that I'm allowing the user to filter on several of these columns, I can't think of a better way of dealing with the data than violating first normal form.
As an example: say that I have several journal articles, each of which may report on multiple animals and multiple vegetables. The user can filter on the source name, or they can filter on one or more animals and one or more vegetables. The output should look like
Source name....animals...............vegetables
Source 1.......dogs, cats, birds.....carrots, tomatoes
Source 2.......leopards, birds.......tomatoes, zucchini, apples
Source 3.......cats, goldfish........carrots, cucumbers
Typically you would have a separate table with Source name + animal:
Source name......animal
Source 1.........dog
Source 1.........cats
Source 1.........birds
Source 2.........leopards
etc
and a similar table for vegetables. But considering how the data needs to be presented to the user (a comma-separated list), and how the user filters the data (he may filter to only see sources that include dogs and cats, and sources with carrots and tomatoes), I think it makes sense to store the data as comma separated lists for animals and vegetables. With a comma-separated list, when the user selects multiple vegetables and multiple animals, I can say
WHERE (Vegetables like "*carrots*" and Vegetables like "*tomatoes*") AND (Animals like *dogs*" and Animals like "*cats*")
I can't think of an efficient way to do this same kind of query in Access without using a lot of VBA and multiple queries.

Answer 1

You can always construct a scenario in which violating any rule makes sense, so the answer to the question in your title is Yes.
This is not one of those scenarios, however. The searching and presentation issues you raise are common to most one-to-many relationships (or, at least, to many one-to-many relationships) and if this were a reason to violate first normal form then you wouldn't see a lot of normalized databases.
Construct the database correctly and you won't have to worry about commas, search terms embedded in each other, and slow searches due to the lack of indexes. Write a reusable piece of code to perform the comma-separate roll-ups for you so you don't keep reinventing the wheel.

Answer 2

i would still normalize this properly - and then worry about the presentation.
in Oracle - this would be done with a user defined aggregate function.

Answer 3

Why not contruct a Join Table so you can sustain the 1:1 in relationship to field referential integrity. Otherwise you will have to parse out the 1:many field value to then get a referential association so everything works magically (hehehe ;))
When i find myself in need to violate the 1st normal form, the answer 9:10 is to create a Join Table and construct some methodology to produce the desired effect.
Edited: 2012-10-09 9:06AM
This design was in response to an unknown amount of information to be displayed in an unknown amount of column/fields. Although mine is oriented towards numerical values, you could simply develop a vba method to concatenate the information fields to produce a singular field of data.
Table1
gid (Number) <- Table2.id
cid (Number) <- Table3.id
price (Number)
gid MANY <- ONE Table2.id
cid MANY <- ONE Table3.id
crt_CategoryPG
TRANSFORM Sum(Table1.price) AS SumOfprice
SELECT View1.tid, Table1.cid, View1.category
FROM Table2 INNER JOIN (View1 INNER JOIN Table1 ON View1.cid = Table1.cid) ON Table2.gid = Table1.gid
WHERE (((Table2.active)=True) AND ((View1.active)=True))
GROUP BY View1.tid, Table1.cid, View1.category, Table2.active, View1.active
ORDER BY View1.tid, Table1.cid
PIVOT [Table2].[gid] & " - " & [Table2].[nm];
Refresh the CT Table
Public Function RefreshCategoryPricing(Optional sql As String = "")
If HasValue(lstType) Then
Application.Echo False 'Turn off Screen Updating
Dim cttbl As String: cttbl = CreateCTTable("crt_CategoryPG") 'Create Table to store the Cross-Tab information
If IsNullOrEmpty(sql) Then
sql = SQLSelect(cttbl)
End If
Dim flds As DAO.Recordset: Set flds = CurrentDb.OpenRecordset(sql)
Dim fldwd As String, fldhd As String 'Store the Field Width pattern and Field Header Row
fldhd = "-1;-1;Category"
fldwd = "0"";0"";2.5""" 'Handles `tid`, `cid`, and `category` columns in the ListBox
'Assign the number of columns based on the number of fields in CTtable
lstCategoryPG.ColumnCount = flds.Fields.Count
Dim fld As Long
For fld = 3 To (flds.Fields.Count - 1)
fldwd = fldwd & ";.75"""
fldhd = fldhd & ";" & flds.Fields(fld).Name
Next
GC flds
lstCategoryPG.ColumnHeads = True
lstCategoryPG.ColumnWidths = fldwd
sql = SQLSelect(cttbl, , ("tid = " & lstType.Value))
lstCategoryPG.Enabled = True
RefreshControl CurrentDb, lstCategoryPG, sql, , False
lstCategoryPG.AddItem fldhd, 0
Application.Echo True 'Turn on Screen Updating
End If
End Function
Create Cross-Tab Table
'#ct - String value, Source Cross-Tab to base Table design off of
Public Function CreateCTTable(ct As String) As String
Dim tbl As String: tbl = "tbl_" & ct
Dim sql As String
If TableExists(tbl) Then
'Table exists and needs to be dropped
sql = SQLDrop(tbl)
CurrentDb.Execute sql
End If
'Create Table
sql = SQLSelect(ct, "* INTO " & tbl)
CurrentDb.Execute sql
CreateCTTable = tbl
End Function