DBMS NORMALIZATION 2nd Normalization Form - database-normalization

Voter(voter_id, voter_name, residential_address, current_city, current_state, current_postal_code).
Postal code is unique for each city and state and each address has only one postal code.
In normalization terms, Voter is in 2nf or 3nf?

To check its highest normal form, follow this basic steps:
First rename the attributes of "Voter" for simplicity.
voter_id as "A"
voter_name as "B"
residential_address as "C"
current_city as "D"
current_state as "E"
current_postal_code as "F"
According to given FD's : {DE -> F , C -> F }
3.Here Candidate keys are: {ABCDE}.
hence,
Prime attributes (5): {A,B,C,D,E} ,
Non Prime attributes (1): {F}
For 2NF:
"Partial Dependencies are not allowed".
Means, A part of candidate key should not determine a non prime attributes.
here ,partial dependencies are : {DE -> F , C -> F }
So, this table is not in 2NF.
**To be into 2NF ,relation should be decompose like this:
R1 ={DEF},
R2 = {CF}
R3 = {ABCDE}
Hope this helps. For more detail like how to decompose a table and all, you can also refer : Detailed explanation of Normal forms

Normalization through BCNF is based on functional dependencies. It's not based on column names, although that seems to be what university students are being taught based on their questions on SO.
I'd presume that "voter_id" is a surrogate key, but that's just educated guesswork. (And that's not a good basis for designing databases.) If it's a surrogate key, then "voter_id" is unique, so we have this FD.
voter_id -> voter_name, residential_address, current_city, current_state, current_postal_code
You said, "Postal code is unique for each city and state . . .", so we also have this FD.
current_city, current_state -> current_postal_code
Finally, you said, ". . . each address has only one postal code".
Based on my experience, I think it's unlikely that you meant residential_address -> current_postal_code. I think you meant that residential_address, current_city, current_state -> current_postal_code. But we already know that current_city, current_state -> current_postal_code, so this doesn't tell us anything useful about functional dependencies.
If there are only these two functional dependencies, then the only candidate key for "voters" is "voter_id".
2NF is concerned with partial key dependencies. The only candidate key is a single column. Therefore, partial key dependencies can't exist. So "voters" is in 2NF.
3NF is concerned with transitive dependencies. There's at least one: voter_id -> current_city, current_state, and current_city, current_state -> current_postal_code. So "voters" is not in 3NF.

Related

How to write constraint involving a certain parameter in clingo?

I am attempting to solve the Google ASP Competition 2019 : Insurance Referee Assignment problem. The problem is provided in this link.
There is a hard constraint that if a referee has preference type of 0 then the case will not be assigned to that referee. I have simplified the problem to include a few variables.
case(cid) refers to a case with cid as the case id.
ref(rid) refers to the referee with referee id.
pref(rid, type) takes the preference of referee 'rid' and type which takes value from 0 to 3. The higher the number, the more likely it will take the case.
In ref(10, 3) and ref(9, 2), the higher preference will be given to ref(10).
I have tried the following clingo code:
ref(rid).
case(cid).
pref(rid, type).
assign(cid, rid) :- ref(rid), pref(rid, type), type != 0.
case(4).
ref(3).
ref(5).
pref(3, 0).
pref(5, 1).
#show assign/2.
However, when I run the command, it shows satisfiable but outputs only this
assign(cid, rid)
What am I doing wrong?
In clingo variables start with a capital letter and are "valid" just withhin the rule. So my guess is you want the following code:
assign(Rcid, Rrid) :- case(Rcid), ref(Rrid), pref(Rrid, Rtype), Rtype != 0.
case(4).
ref(3). ref(5).
pref(3, 0). pref(5, 1).
#show assign/2.
output:
Solving...
Answer: 1
assign(4,5)
SATISFIABLE
Please note that only renaming the constants to variable names will result in an error message, you have to add case(Rcid) to the rule body as well. Variable names were freely choosen, you can use any variable name as long as it starts with a capital letter.

UIMA RUTA annotation at the beginning of sequence

I have sequence of annotations that are instances of the same type (e.g. sequence of CW annotations). I need to remove the first of them (more formally: remove annotation that has no annotations of the same type before in document). Less formally: to remove an annotation at the beginning of document. Example document: "Software StageTools"
So, I tried many variants:
"Software"{-AFTER(CW) -> UNMARK(CW)} CW+; //does not work
"Software"{BEFORE(CW) -> UNMARK(CW)} CW+; //does not work
"Software"{-STARTSWITH(Document) -> UNMARK(CW)} CW+; //does not work
CW{0, 0} "Software"{-> UNMARK(CW)} CW+; //getting parsing error
...and some other ones. Obviously, no one works (may be, I can refer to begin feature of annotation, but this will not solve formal issue).
At last, the question is - how can I say RUTA to remove annotation that has no annotations of the same type before in document?
There are many ways to do this. Here are two examples:
# cw:CW.ct=="Software"{-> UNMARK(cw)} CW;
Remove the first CW "Software" in the document if there is another CW following.
ANY{-PARTOF(CW)} cw:#CW.ct=="Software"{-> UNMARK(cw)} CW;
Remove any CW "Software" if there is a CW following and there is no CW preceding. If the document can start with the pattern, you need a second rule.
Your second rule actually works for me. The last rule has no valid syntax. The min/max quantifier requires different brackets like [0,0]. However, this would not have the effect you want.
DISCLAIMER: I am a developer of UIMA Ruta

Play for Scala - more than one .verifying criteria when mapping?

I'm new to both Scala and Play, currently working through Chapter 2 of 'Play for Scala' and have a query about the 'Products' application.
The application features a barcode generator that needs a longNumber value with 11 or 12 characters, but there is no validation in place to check that the longNumber has the correct number of characters. This means that the barcode image does not always generate correctly.
Current verification, provided by the book, is:
private val productForm: Form[Product] = Form(
mapping(
"ean" -> longNumber.verifying(
"validation.ean.duplicate", Product.findByEan(_).isEmpty),
"name" -> nonEmptyText,
"description" -> nonEmptyText
)(Product.apply)(Product.unapply)
)
Is there any way to add another set of 'verifying' criteria to the "ean" value? Ideally to check whether "ean" is long enough, and if not display a "validation.ean.length" message.
Many thanks
Mapping.verifying returns a new Mapping, so you can just call verifying again on it. You can chain as many of these as you like this way.

UIMA Ruta: Copy the feature value from a contained annotation to a containing annotation

Note: This seems heavily related to Setting feature value to the count of containing annotation in UIMA Ruta. But I cannot quite apply the answer to my situation.
I am analyzing plain text documents where the following structure is assumed:
Document (one, of course)
Section (many)
Heading (one per section)
I am being asked to identify sections by checking whether their headings satisfy conditions. A useful and obvious sort of condition would be: does the heading match a given regular expression? A less-useful but perhaps more achievable condition would be: does the heading contain a given text?
I could and have already achieved this by taking a list of tuples of regular expressions and section titles, and at design time, for each member of the list, as such:
BLOCK(forEach) SECTION{} {
...
HEADING{REGEXP(".*table.*contents.*", true) ->
SETFEATURE("value", "Table of Contents")};
...
}
SECTION{ -> SETFEATURE("value", "Table of Contents")}
<- { HEADING.headingValue == "Table of Contents"; };
This approach is fairly straightforward but has a few big drawbacks:
It heavily violates the DRY principle
Even when writing the rule for just one section to identify, the rule author must copy the section title twice (it should only need to be specified once)
It makes the script needlessly long and unwieldy
It puts a big burden on the rule author, who in an ideal case, would only need to know Regex - not Ruta
So I wanted to refactor to achieve the following goals:
A text file is used to store the regular expressions and corresponding titles, and the rule iterates over these pairs
Features, rather than types, are used to differentiate different sections/headings (i.e. like above, using SECTION.value=="Table of Contents" and not TableOfContentsSection)
After looking over the UIMA Ruta reference to see which options were available to achieve these goals, I settled on the following:
Use a WORDTABLE to store tuples of section title, words to find / regex if possible, lookup type - so for instance, Table of Contents,contents,sectiontitles
Use MARKTABLE to mark an intermediate annotation type LookupMatch whose hint feature contains the section title and whose lookup feature contains the type of lookup we are talking about
For each HEADING, see if a LookupMatch.lookup == "sectiontitle" is inside, and if it is, copy the LookupMatch.hint to the heading's value field.
For each SECTION, see if a HEADING with a value is inside; if so, copy the value to the SECTION.value field.
It was not quite a surprise to find that implementing steps 3 and 4 was not so easy. That's where I am at and why I am asking for help.
// STEP 1
WORDTABLE Structure_Heading_WordTable =
'/uima/resource/structure/Structure_Heading_WordTable.csv';
// STEP 2
Document.docType == "Contract"{
-> MARKTABLE(LookupMatch, // annotation
2, // lookup column #
Structure_Heading_WordTable, // word table to lookup
true, // case-insensitivity
0, // length before case-insensitivity
"", // characters to ignore
0, // matches to ignore
"hint" = 1, "lookup" = 3 // features
)
};
// STEPS 3 AND 4 ... ???
BLOCK(ForEach) LookupMatch.lookup == "sectiontitle"{} {
???
}
HEADING{ -> SETFEATURE("value", ???)} <- {
???
};
Here is my first real stab at it:
HEADING{ -> SETFEATURE("value", lookupMatchHint)} <- {
LookupMatch.lookup == "HeadingWords"{ -> GETFEATURE("hint", lookupMatchHint)};
};
TL; DR
How can I conditionally copy a feature value from one annotation to another? GETFEATURE kind of assumes that you only get 1...

How to express queries in Tuple Relational Calculus?

Problem:
Consider a relation of scheme Building(Street, Number, No.Apartments, Color, Age).
TRC: find the oldest building in Downing Street.
The associated SQL statement would be:
SELECT MAX(Age) AS ‘Oldest building’, Street FROM Building WHERE Street = ‘Downing Street’;
My answer using TRC: (B stands for Building relation)
{V.*|V(B) | V.BAge >=Age ^ V.Bstreet = ‘Downing Street’}
V.* (it returns evry single tuple of Building)
V(B) (it maps variables V to Building’s tuples)
V.BAge >=Age ^ V.Bstreet = ‘Downing Street’(here I set the condition…maybe..)
If this is still relevant: the hint would be to realize that the oldest building is the one such that no other building is older than it.