I'm working on a college exercise and have the following question:
What is the domain of the "country" table?
My understanding of domain is that it defines the possible values of an attribute.
This means that the table "country" doesn't have a domain, but the various attributes in the table "country" have their own domains.
For example the attribute "SurfaceArea" has the domain FLOAT(10,2) and the attribute "Name" has the domain CHAR(52).
Is this correct?
http://en.wikipedia.org/wiki/Relational_database#Domain
Here is one source and yes, you are correct, domain describes the possible values of an attribute.
Your understanding of domains is correct but not complete. Typically, a domain is implemented as a data type like you specified. However, a domain can be more specific than the data type. Consider the attribute Grade, the possible values could be {A, B, C, D, F, I}. If you specify the data type as CHAR(1) then you are not eliminating invalid letters like G, H, J, etc. Consequently, it is important to understand what the original domain is and how it is different from the domain of the data type. Any remaining constraints such as eliminating those invalid values are typically implemented as an application constraints.A good reference on this is Elmasry and Navathe.
Related
Currently, we are developing an API for our system and there are some resources that may have different kinds of identifiers.
For example, there is a resource called orders, which may have an unique order number and also have an unique id. At the moment, we only have URLs for the id, which are these URLs:
GET /api/orders/{id}
PUT /api/orders/{id}
DELETE /api/orders/{id}
But now we need also the possibility to use order numbers, which normally would result into:
GET /api/orders/{orderNumber}
PUT /api/orders/{orderNumber}
DELETE /api/orders/{orderNumber}
Obviously that won't work, since id and orderNumber are both numbers.
I know that there are some similar questions, but they don't help me out, because the answers don't really fit or their approaches are not really restful or comprehensible (for us and for possible developers using the API). Additionally, the questions and answers are partially older than 7 years.
To name a few:
1. Using a query param
One suggests to use a query param, e.g.
GET /api/orders/?orderNumber={orderNumber}
I think, there are a lot of problems. First, this is a filter on the orders collections, so that the result should be a list as well. However, there is only one order for the unique order number which is a little bit confusing. Secondly, we use such a filter to search/filter for a subset of orders. Additionally, a query params is some kind of a second-class parameter, but should be first-class in this case. This is even a problem, if I the object does not exist. Normally a get would return a 404 (not found), but a GET /api/orders/?orderNumber=1234 would be an empty array, if the order 1234 does not exist.
2. Using a prefix
Some public APIs use some kind of a discriminator to distinguish between different types, e.g. like:
GET /api/orders/id_1234
GET /api/orders/ordernumber_367652
This works for their approach, because id_1234 and ordernumber_367652 are their real unique identifiers that are also returned by other resources. However, that would result in a response object like this:
{
"id": "id_1234",
"ordernumber": "ordernumber_367652"
//...
}
This is not very clean, because the type (id or order number) is modelled twice. And apart from the problem of changing all identifiers and response objects, this would be confusing, if you e.g. want to search for all order numbers greater than 67363 (thus, there is also a string/number clash). If the response does not add the type as a prefix, a user have to add this for some request, which would also be very confusing (sometime you have to add this and sometimes not...)
3. Using a verb
This is what e.g. Twitter does: their URL ends with show.json, so you can use it like:
GET /api/orders/show.json?id=1234
GET /api/orders/show.json?number=367652
I think, this is the most awful solution, since it is not restful. Furthermore, it has some of the problems that I mentioned in the query param approach.
4. Using a subresource
Some people suggest to model this like a subresource, e.g.:
GET /api/orders/1234
GET /api/orders/id/1234 //optional
GET /api/orders/ordernumber/367652
I like the readability of this approach, but I think the meaning of /api/orders/ordernumber/367652 would be "get (just) the order number 367652" and not the order. Finally, this breaks some best practices like using plurals and only real resources.
So finally, my questions are: Did we missed something? And are there are other approaches, because I think that this is not an unusual problem?
to me, the most RESTful way of solving your problem is using the approach number 2 with a slight modification.
From a theoretical point of view, you just have valid identification code to identify your order. At this point of the design process, it isn't important whether your identification code is an id or an order number. It's something that uniquely identify your order and that's enough.
The fact that you have an ambiguity between ids and numbers format is an issue belonging to the implementation phase, not the design phase.
So for now, what we have is:
GET /api/orders/{some_identification_code}
and this is very RESTful.
Of course you still have the problem of solving your ambiguity, so we can proceed with the implementation phase. Unfortunately your order identification_code set is made of two distinct entities that share the format. It's trivial it can't work. But now the problem is in the definition of these entity formats.
My suggestion is very simple: ids will be integers, while numbers will be codes such as N1234567. This approach will make your resource representation acceptable:
{
"id": "1234",
"ordernumber": "N367652"
//...
}
Additionally, it is common in many scenarios such as courier shipments.
Here is an alternate option that I came up with that I found slightly more palatable.
GET /api/orders/1234
GET /api/orders/1234?idType=id //optional
GET /api/orders/367652?idType=ordernumber
The reason being it keeps the pathing consistent with REST standards, and then in the service if they did pass idType=orderNumber (idType of id is the default) you can pick up on that.
I'm struggling with the same issue and haven't found a perfect solution. I ended up using this format:
GET /api/orders/{orderid}
GET /api/orders/bynumber/{orderNumber}
Not perfect, but it is readable.
I'm also struggling with this! In my case, i only really need to be able to GET using the secondary ID, which makes this a little easier.
I am leaning towards using an optional prefix to the ID:
GET /api/orders/{id}
GET /api/orders/id:{id}
GET /api/orders/number:{orderNumber}
or this could be a chance to use an obscure feature of the URI specification, path parameters, which let you attach parameters to particular path elements:
GET /api/orders/{id}
GET /api/orders/{id};id_type=id
GET /api/orders/{orderNumber};id_type=number
The URL using an unqualified ID is the canonical one. There are two options for the behaviour of non-canonical URLs: either return the entity, or redirect to the canonical URL. The latter is more theoretically pure, but it may be inconvenient for users. Or it may be more useful for users, who knows!
Another way to approach this is to model an order number as its own thing:
GET /api/ordernumbers/{orderNumber}
This could return a small object with just the ID, which users could then use to retrieve the entity. Or even just redirect to the order.
If you also want a general search resource, then that can also be used here:
GET /api/orders?number={orderNumber}
In my case, i don't want such a resource (yet), and i could be uncomfortable adding what appears to be a general search resource that only supports one field.
So basically, you want to treat all ids and order numbers as unique identifiers for the order records. The thing about unique identifiers is, of course, they have to be unique! But your ids and order numbers are all numeric; do their ranges overlap? If, say, "1234" could be either an id or an order number, then obviously /api/orders/1234 is not going to reference a unique order.
If the ranges are unique, then you just need discriminator logic in the handler code for /api/orders/{id}, that can tell an id from an order number. This could actually work, say if your order numbers have more digits than your ids ever will. But I expect you would have done this already if you could.
If the ranges might overlap, then you must at least force the references to them to have unique ranges. The simplest way would be to add a prefix when referring to an order number, e.g. the prefix "N". So that if the order with id 1234 has order number 367652, it could be retrieved with either of these calls:
/api/orders/1234
/api/orders/N367652
But then, either the database must change to include the "N" prefix in all order numbers (you say this is not possible) or else the handler code would have to strip off the "N" prefix before converting to int. In that case, the "N" prefix should only be used in the API calls - user facing data-entry forms should not expose it! You can't have a "lookup by any identifier" field where users can enter either id or order number (this would have a non-uniqueness problem anyway.) Instead, you must have separate "lookup by id" and "lookup by order number" options. Then, you should be able to have the order number input handler automatically add the "N" prefix before submitting to the API.
Fundamentally, this is a problem with the database design - if this (using values from both fields as "unique identifiers") was a requirement, then the database fields should have been designed with this in mind (i.e. with non-overlapping ranges) - if you can't change the order number format, then the id format should have been different.
I have override the existing Patient Registration form and render the Xform Patient Registration from successfully[Reference].
When I create a new Patient I'm getting following error
"Patient#null failed to validate with reason :Invalid check digit for identifier:10005G".
I given following information for patient creation
Family Name: Patient
Given Name:One
DOB:30/12/2000
Identifier :10005C
Gender:M
Location:Unknow Location
Identifier Type:Old Identification Number Other
Other Identifiers
Identifiers Identifier :10005G
Identifier Type:OpenMrs ID Identifer
Location:Unknow Location
Some please help how to fix the issue.
OpenMRS uses a modified Luhn Algorithm to calculate check digits, where the last character in an identifier is calculated from the preceding characters. Check digits allow for self-validation of identifiers that are manually entered (an approach also used by the credit card industry). The default algorithm used for new identifier types is a Luhn Mod-30 Check Digit Validator. This Mod-30 algorithm uses the character set "0123456789ACDEFGHJKLMNPRTUVWXY" for characters within identifiers and check digits (avoiding letters that may be confused with numbers or other letters: B, I, O, Q, S, and Z).
Presumably, this algorithm is being applied to your supplied identifier(s). The correct Mod-30 check digit for "10005" is "K" (not "C" or "G"). This is probably why you are getting the error. The algorithm used, if any, to validate identifiers depends on the Patient Identifier Type, so you can figure out which algorithm(s) are being used on your system by looking at the patient identifier types defined in your system.
I have a normalization problem like the following:
R={
att1(nb1, nb2, nb3),
att2, val1, val2, def1, class1,
class2{notion1, notion2},
def2,col1
}
Here, attr1 is a multi-valued attribute and class2 is a composite attribute.
How do I convert R to 1NF?
Is it like the following?
R={
nb1, nb2, nb3,
att2, val1, val2, def1, class1,
notion1, notion2,
def2,col1
}
Yes, your answer is correct. As it is said in Wikipedia:
A relation is in first normal form if the domain of each attribute contains only atomic values, and the value of each attribute contains only a single value from that domain.
In other words, you cannot have attributes that:
are structured, that is contain components, or
are repeated (or both).
So, att1 and class2 must be substituted by their components.
Note that in the result relation you have different rows with the same values for all the other attributes different from nb1, nb2 and nb3.
This normal form has been introduced initially in a paper by E. Codd, in 1971: E. F. Codd, Further normalization of the database relational model, Courant Institute: Prentice-Hall, ISBN 013196741X,
A relation is in first normal form if it has the property that none of its domains has elements which are themselves sets.
(see Wikipedia citation).
This normal form is nowday presented in all the books on relational theory only for historical reasons, since this property is now considered part of the Relational Database Model. See for instance the book Fundamentals of database systems, by R. Elmasri, S. Navathe, Addison Wesley (pag.519 of the 6th edition, ISBN: 978-0-13-608620-8):
First Normal Form
First normal form (1NF) is now considered to be part of the formal definition of a relation in the basic (flat) relational model; historically, it was defined to disallow multivalued attributes, composite attributes, and their combinations. It states that the domain of an attribute must include only atomic (simple, indivisible) values and that the value of any attribute in a tuple must be a single value from the domain of that attribute. Hence, 1NF disallows having a set of values, a tuple of values, or a combination of both as an attribute value for a single tuple. In other words, 1NF disallows relations within relations or relations as attribute values within tuples. The only attribute values permitted by 1NF are single atomic (or indivisible) values.
While going through the definition link base of a taxonomy, i found that a few domain members were present in two separate dimensions. Eg. Dim A contains domain Dom1 with members m1, m2,m3,m4. And Dim B contains domain dom2 with members m2,m3,m4. The issue is that it may lead to conflicting context names (even though the segment part of the contexts will be different).
The format of the context name is 'periodInformation_domainMember'. I need to use different dimensions for different sections of my report. So my basic question is how do i form context names?
I hope i have conveyed myself properly.
Appreciate any help... :)
use "Period Information + Dimension + member name" for making context names unique.....
You have to check the uniqueness based on the child nodes of <period> tag and child nodes of the <segment> tag... here in segment; if segment is present then each xbrldi:explicitMember has dimension in its attribute and member in its value...
...more: http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2005-04-25.htm#_4.7
What if there were multiple dimensions? Playing devil's advocate, what if you have dimensions with the same local name but in different namespaces? The only way to guarantee a unique name is to use the whole content of the context - which is ridiculous.
I've seen recommendations by regulators requiring filings in XBRL that 'Semantics SHOULD NOT be expressed...' in a context id and it is '..recommended to keep it as short as possible...'
The simplest solution is to pick unique names that that have nothing to do with the contents - for example c-1, c-2 etc.
The syntax of the XBRL is unimportant, it's just an implementation detail.
Say I have a table called Users, which contains your typical information: Id, Name, Street, City--much like in the example here:
http://weblogs.asp.net/manavi/archive/2010/12/11/entity-association-mapping-with-code-first-part-1-one-to-one-associations.aspx.
Among other things, this article states:
"Code First has a concept of Complex Type Discovery that works based on a set of Conventions. The convention is that if Code First discovers a class where a primary key cannot be inferred, and no primary key is registered through Data Annotations or the fluent API, then the type will be automatically registered as a complex type. Complex type detection also requires that the type does not have properties that reference entity types (i.e. all the properties must be scalar types) and is not referenced from a collection property on another type." My Address class meets these criteria: it's made up of strings and isn't used anywhere else.
In the app, though (I'm not sure if this makes any difference), we're calling the Users something else--say, Techs. I want to break out User's address columns into an Address so each Tech can have its own Address. According to the article above, EF should infer this and take care of the complex type automatically. What I'm getting,though, when the context attempts to give me a Tech, is the following exception:
System.Data.EntityCommandExecutionException: An error occurred while executing t
he command definition. See the inner exception for details. ---> System.Data.Sql
Client.SqlException: Invalid column name 'Address_Street'.
Invalid column name 'Address_City'.
Invalid column name 'Address_State'.
Invalid column name 'Address_Zip'.
It looks like it's trying to make sense of the Tech.Address property, but is giving each of its sub-properties the wrong name (e.g., "Address_City" instead of "City").
Any ideas on how I can rectify this?
That is correct behavior. Default convention always prefixes properties mapped to complex type with type name. If you want to use different column names you must map them either through data annotations:
public class Address
{
[Column("City")]
public string City { get; set; }
...
}
or through fluent API:
modelBuilder.ComplexType<Address>().Property(a => a.City).HasColumnName("City");