Primary key does not imply an index... indexed primary key is just a performance feature. In Oracle RDBMS they have made it mandatory, but the only reason for that is performance, there is no fundamental need to have an index on primary key column(s). Oracle has solved it using a B-tree derivative, others (like TimesTen) have solved it using hash index, others might be using yet another approach. That's the physical layer. So, indexing, including primary key indexing should be responsibility of DBA/physical designer role, not data modeler role (unless, as Jared said, the data modeler happens to be a DBA too). Of course a very good data modeler should at least be aware of the implications of physical layer, just as a very good DBA must understand the OS below the databases. Tanel. _____ From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Mark Brinsmead Sent: Saturday, October 28, 2006 10:54 To: Jared Still Cc: Christian Antognini; oracle-l@xxxxxxxxxxxxx Subject: Re: RMAN impact True enough! Sort of. Except that a primary key implies an index. As does a foreign key. (Actually, unless you're crazy, many foreign keys will imply two indexes, one on each table.) Conversely, no indexes means no primary keys. In my personal fantasy world, lack of Primary Keys means unemployed data modelers, but sadly the so-called real-world seems to be quite different... ;-) A (logical) data model may not specify indexes, but if it's done correctly, it's going to imply at least one on every table. If the physical data model fails to embody those indexes, then somebody ought to be in trouble! ;-)