relational-database

Working with databases, how can I find MAX using relational algebra? Assuming you have a relation, A, with a single attribute, 'a' (reducing a more complex relation to this is a simple task in relational algebra, I'm sure you got this far), so now you want to find the maximum value in A. One way to do it is to find the cross product of A with itself, be sure to rename 'a' so your new relation has attributes with distinct names. for example: (rename 'a' as 'a1') X (rename 'a' as 'a2') now select 'a1' < 'a2', the resulting relation will have all values except the maximum. To get the max simply

This example is taken from w3schools . CREATE TABLE Persons ( P_Id int NOT NULL, LastName varchar(255) NOT NULL, FirstName varchar(255), Address varchar(255), City varchar(255), CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName) ) My understanding is that both columns together ( P_Id and LastName ) represent a primary key for the table Persons . Is this correct? Why would someone want to use multiple columns as primary keys instead of a single column? How many columns can be used together as a primary key in a given table? MJB Your understanding is correct. You would do this in many cases. One

I have the following tables in a relational database: [Sensor] LocationId [PK / FK -> Location] SensorNo [PK] [AnalogSensor] LocationId [PK/FK -> Sensor] SensorNo [PK/FK -> Sensor] UpperLimit LowerLimit [SwitchSensor] LocationId [PK/FK -> Sensor] SensorNo [PK/FK -> Sensor] OnTimeLimit [Reading] LocationId [PK/FK -> Sensor] SensorNo [PK/FK -> Sensor] ReadingDtm [PK] [ReadingSwitch] LocationId [PK/FK -> Reading] SensorNo [PK/FK -> Reading] ReadingDtm [PK/FK -> Reading] Switch [ReadingValue] LocationId [PK/FK -> Reading] SensorNo [PK/FK -> Reading] ReadingDtm [PK/FK -> Reading] Value [Alert]

I need to store a set of entities, of which there are several specialized versions. They have some common properties, but the specialized ones contain properties specific for that entity. Solutions The data store is a relational DBMS, and this is not for discussion :-) Specifically, it is the Microsoft SQL Server 2005. I could easily create a table for the common properties and then a table for each of the specialized versions. However, it is likely that new entities will have to be added to the solution later and I don't want to maintain both an object model and a database schema. Another

I've been trying to see if I can accomplish some requirements with a document based database, in this case CouchDB. Two generic requirements: CRUD of entities with some fields which have unique index on it ecommerce web app like eBay ( better description here ). And I'm begining to think that a Document-based database isn't the best choice to address these requirements. Furthermore, I can't imagine a use for a Document based database (maybe my imagination is too limited). Can you explain to me if I am asking pears from an elm when I try to use a Document oriented database for these

I have read the quote : data depends on the key [1NF], the whole key [2NF] and nothing but the key [3NF] . However, I am having trouble understanding 3.5NF or BCNF as it's called. Here is what I understand : BCNF is stricter than 3NF left side of any FD in the table must be a superkey (or at least a candidate key) So why is it then, that some 3NF tables are not in BCNF? I mean, the 3NF quote explicitly says "nothing but the key" meaning that all attributes depend solely on the primary key. The primary key is, after all, a candidate key until it is chosen to be our primary key. If anything is