Let assume that I have an empty database and I want to create two tables. There is a relationship between them. For example, one of attributes (call them b) in R is a foreign key. The definition SHOULD (database is empty, I have not executed any statement, yet) look:
create table R(
a type primary key,
b type references S(b)
);
create table S(
b type primary key
);
If I try run script with statements as above, I get error (according to line: b type references S(b)) , because S doesn't exist - that is normal and natural. It is possible to disable checking existing of tables, coresponding to foreign keys?
I know I can change order of statements. Or create tables without constraints, and add them later.
Why I'm asking. Let assume that we have many tables, with many relationships between them. Ordering tables manually will consume a lot of time, when we will want prepare kind of 'backup script'.
I know that it is possible to disable constraint as below:
alter table table_name disable constraint_name;
But that works for example with insert statement. There is a solution proper to create statement?
Related
I want to create a table with a column that references the name of a sequence I've also created. Ideally, I'd like to have a foreign key constraint that enforces this. I've tried
create table testtable (
sequence_name varchar2(128),
constraint testtableconstr
foreign key (sequence_name)
references user_sequences (sequence_name)
on delete set null
);
but I'm getting a SQL Error: ORA-01031: insufficient privileges. I suspect either this just isn't possible, or I need to add something like on update cascade. What, if anything, can I do to enforce this constraint when I insert rows into this table?
I assume you're trying to build some sort of deployment management system to keep track of your schema objects including sequences.
To do what you ask, you might explore one of the following options:
Run a report after each deployment that compares the values in your table vs. the data dictionary view, and lists any discrepancies.
Create a DDL trigger which does the insert automatically whenever a sequence is created.
Add a trigger to the table which does a query on the sequences view and raises an exception if not found.
I'm somewhat confused at what you are trying to achieve here - a sequence (effectively) only has a single value, the next number to be allocated, not all the values that have been previously allocated.
If you simply want to ensure that an attribute in the relation is populated from the sequence, then a trigger would be the right approach.
The diagram has over 40 tables, most of them have a primary key defined.
For some reason there is this one table, which has a primary key defined, but that's being ignored when I export the model to a DDL script.
This is the "offending" key (even though it's checked it is nowhere to be found on the generated DDL script):
Has anybody had the same problem? Any ideas on how to solve it?
[EDIT] This is where the key is defined:
And this is the DDL preview (yes, the primary key shows up there):
This is what happens if I try to generate the DDL for just that table (primary key still not generated):
I was finally able to identify and reproduce the problem.
It was a simple conflict of constraints.
Table MIEMBROS had a mandatory 1 to n relationship (foreign key) from another table on its primary key column and vice-versa (there was a foreign key on MIEMBROS against the other table's primary key).
This kind of relationship between two tables makes it impossible to add a record to any of them: The insert operation will return an error complaining about the foreign key restriction pointing the other table.
Anyway I realized that one of the relationships was 0 to n so I simply unchecked the "mandatory" checkbox on the foreign key definition and everything went fine.
So, in a nutshell: The Data Modeler "fails" silently if you are defining a mutual relationship (two foreign keys, one on each table against the other table) on non nullable unique columns, by not generating the primary key of one of the tables.
Such an odd behavior, if you ask me!
"This kind of relationship between two tables makes it impossible to add a record to any of them: The insert operation will return an error complaining about the foreign key restriction pointing the other table."
Actually, if you have deferred constraints, this is not impossible. The constraints can be enforced, for example, at commit time rather than immediately at insert time.
From the Data Modeler menu under File, I used Export -> DDL File. The keys appeared in the DDL, then when I went back to the diagram and did DDL Preview, it showed all the missing stuff.
I have one table - TableA. This is source and target also. Table doesn't have any primary key. I am fetching data from TableA, then doing some calculation on some fields and updating them in same tableA. Now how can I update data when it doesn't have any primary key or composite key? Second question - If joining two columns make a record unique then how can I use it in informatica?Plz help
You can define the update statement in the target. There is that properties.
Still you have to make informatica to perform an update, not insert. To do that you need to use the update strategy.
I think you don't need in this solution to make any PK on that table, because you will use your own update statement, but please verify this.
To set the fields and make proper where condition for update you need to use :TU alias in the code. TU -> means the update strategy before the target.
Example:
update t_table set field1 = :TU.f1 where key_field = :TU.f5
If you don't want (or can't) create primary key in your table in database you can just define it in informatica source
If record unique as combination of two columns just mark both of them as primary key in informatica source
This question is a duplicate in meaning still I have to clarify it. Oracle documentation specifically says that it is possible to specify a primary key in CREATE VIEW clause(11g docs has the same notion) . Yet when I try to do it like this:
create or replace view ABC(A, B, C, CONSTRAINT A_PK PRIMARY KEY (A)) ....
I get ORA-00922: missing or invalid option pointing at "primary key" phrase. The question is, is it me or is it something wrong with Oracle Documentation?
The simple answer is that your syntax is incorrect. You must specify DISABLE.
NOVALIDATE disables validation of the primary key, in a view this is the default and so is included automatically; but it's a lot clearer if you use it, as, in a lovely double negative, disable novalidate disables the ability to disable the primary key.
The rely is optional; it specifies whether to take into account the primary key when creating the view. The antonym of rely is norely.
There are a lot of restrictions on creating a view constraint and as it relies on the table below it's not really worth it as already noted by #RC. But if you need it for documentation only then here you go:
SQL> create table tmp_test ( a number(10), b varchar2(120) );
Table created.
SQL>
SQL> insert into tmp_test
2 select level, 'b'
3 from dual
4 connect by level <= 20
5 ;
20 rows created.
SQL> commit ;
Commit complete.
SQL>
SQL> alter table tmp_test
2 add constraint tmp_test_pk
3 primary key (a)
4 using index;
Table altered.
SQL>
SQL> create or replace view v_tmp_test (a, b
2 , constraint v_tmp_test_pk primary key (a) rely disable novalidate) as
3 select a, b
4 from tmp_test
5 ;
View created.
SQL>
From the documentation:
View Constraints
Oracle does not enforce view constraints. However, operations on views
are subject to the integrity constraints defined on the underlying
base tables. This means that you can enforce constraints on views
through constraints on base tables.
Notes on View Constraints View constraints are a subset of table
constraints and are subject to the following restrictions:
You can specify only unique, primary key, and foreign key constraints
on views. However, you can define the view using the WITH CHECK OPTION
clause, which is equivalent to specifying a check constraint for the
view.
View constraints are supported only in DISABLE NOVALIDATE mode. You
cannot specify any other mode. You must specify the keyword DISABLE
when you declare the view constraint. You need not specify NOVALIDATE
explicitly, as it is the default.
The RELY and NORELY parameters are optional. View constraints, because
they are unenforced, are usually specified with the RELY parameter to
make them more useful. The RELY or NORELY keyword must precede the
DISABLE keyword. Please refer to "RELY Clause" for more information.
Because view constraints are not enforced directly, you cannot specify
INITIALLY DEFERRED or DEFERRABLE.
You cannot specify the using_index_clause, the exceptions_clause
clause, or the ON DELETE clause of the references_clause.
You cannot define view constraints on attributes of an object column.
You have to create the constraint as disabled. It is really a way to give a hint to the optimizer to influence the query plan.
Data integrity is enforced at the underlying table level. When you think about it, enforcing a primary key constraint at the view level doesn't make a whole lot of sense. A plain ole view doesn't store data, it is just a "view" of data provided by other tables. If a primary key constraint was only placed on a view of some underlying table and that table does not enforce the constraint itself, how would the view handle the situation where someone updated the table directly with data that breaks it's constraint? (i.e. the table has no idea what constraints are placed on it via a view)
I'm storing multiple hierarchies within an Oracle table (standard model of parent, child, root columns) and was interested in finding out what constraints I should consider to make sure the hierarchy remains correct and valid.
I'd like to ensure that for each row the child, parent and root columns all make sense (eg. the same root can not be defined for two different hierarchies, if a child exists so does it's parent, etc.)
I know from working with linked tables that were defined with no constraints (!!) inconsistent/incomplete data always creeps in one way or another no matter how carefully the application tries to avoid it.
Now considering triggers should generally be avoided for all but the simple cases and I can't see how to code a constraint for this, is a stored procedure the only real way to go (presumably with a serializable transaction mode set)?
You can not define foreign key referring the same table of the constraint in the CREATE TABLE statement, but you could do it with an ALTER TABLE statement.
create table XXX (
key number primary key,
parent number
)
/
alter table XXX add constraint XXX_FK foreign key (parent) references XXX
/