Hi all,

I am trying to get my head around DB theory,

I have the following information regarding an airplane,

AIRPLANE
manufacturer,
type,
serial number,
purchase date,
length,
weight,
Span,
max. flying altitude,


What I am trying to figure out is if airplane_type should be its own
Entity or simply an attribute of Airplane and why(or in which cases),

perhaps more info required?

thanks

Portroe

portroe wrote:

First off: IS airplane_type simply a tag, or does it carry a meaning
unto itself, ie. could you imagine attributes associated with
airplane_type?

Secondly, even if it is simply a tag, you might consider defining it
as an entity as it gives you some possibilities:
- a short tag with a longer named as an attribute
- enforcement of integrity (only *these* airplane_type's are allowed
in the database). Entegrity may of course be enforced in other ways
too, but this way allows you to centralize the definition of possible
types.

And last: There is no correct answer.

More info is always required :-(

--
Kristian Damm Jensen
damm (at) ofir (dot) dk

Hi,

portroe schrieb:
I will do it very simple. Ask a single question:
Does an airplane_type have its own attributes or behaviour in the
relevant miniworld? If yes, you make it an own relation.

Have a look on your attributes in the relation AIRPLANE. It seems to me
that some of the attributes are related (functional dependent) to an
airplane (e.g. serial number, purchase date), others to the airplane
type (e.g. length, weight and other technical details) and others to up
to now not identified relations - probably the manufacturer will be an
own relation.

How to deal with the manufacturer? Ask the same question.

The answers to these questions gives you a first look on the functional
dependencies between your attributes in your miniworld.

--
Mit freundlichen Grüßen / Best regards
Michael Gast
SEPP MED GmbH

All emails sent to this address are never read and never will be
answered. Sorry, but until someone cleans up the spam mess, that's the
way it has to be.

E-Mails, die direkt an diese Adresse geschickt werden, lese und
beantworte ich nicht. Ich bedauere diesen Umstand sehr, kenne derzeit
aber keine bessere Möglichkeit, um die Spam-Flut abzustellen.

portroe <portroe (AT) nospam (DOT) com> wrote

Airplane_type definitely *could* be its own entity (or relation according
to relational theory).
If you want to exclude nonexistant types in AIRPLANE, then it *should*
be an entity on its own.

If you are beginning in database theory, the next question is: what
attributes belong to AIRPLANE_TYPE instead of AIRPLANE. Does your database
allow modified airplanes, resulting in different wingspan (etc.) of the
same type?
This is usually phrased as "the identifying key determines the non-key
columns". It may be easier to look at it from the opposite side:
"the non-key columns fully depend on the identifying key".

"Theo Peterbroers" <peterbroers (AT) floron (DOT) leidenuniv.nl> wrote

According to relational theory, we should have adequate support for domains
to obviate the need for such 'domain relations'.

"Kristian Damm Jensen" <REdammMOVE (AT) ofir (DOT) dk> wrote

You must also ask whether those attributes are time-varying.


Actually, there is a correct answer. If the derivable attributes or
representations are time varying, one requires a relation. If they are not
time varying, one has a domain.

The question then becomes: Does your dbms adequately support domains?


True.