How to add a foreign key to a mysql table:

alter table line_items add FOREIGN KEY fk_line_item_orders (product_id) references orders(id);

Recently we had a story which involved improving one of our data models. The table for the model had grown quite wide and we wanted to improve normalization and performance. We wanted to move a few columns from our original table (Listing) to a new table with the primary key of the new table (ListingLocation) also being a foreign key to the primary key of the original table, our one-to-one relationship. I will try to detail how we accomplished this change using a simplified example. Source code is linked at the bottom of this post.

Here is the entity relationship diagram of the old, single table structure:

And here is the entity relationship diagram of the new, two table structure:

As you can see, it is a very simple example of a very common relationship in the database. However, what we found when implementing this in Hibernate was not a simple as I had hoped.

To get started here is the SQL used to represent our new tables:

CREATE TABLE Listing
(
id BIGINT(20) NOT NULL AUTO_INCREMENT,
price DECIMAL(10,2),
PRIMARY KEY (id)
) TYPE = INNODB;

CREATE TABLE ListingLocation
(
listingID BIGINT(20) NOT NULL,
address VARCHAR(255),
PRIMARY KEY(listingID),
INDEX (listingID),
FOREIGN KEY (listingID) REFERENCES Listing (id)
) TYPE = INNODB;


I’ve used MySQL for this example because it is free and easy to setup. InnoDB table types have been because they allow foreign keys, which is crucial to this example.

Our old Listing entity was pretty basic; it looked something like this (imports & getters/setters excluded):

@Entity
@Table
public class Listing implements Serializable {
@Id
@GeneratedValue
private long id;
@Column(columnDefinition= "DECIMAL(10,2)")
private double price;
private String address;
...

In this case, creating a new instance of Listing and persisting it is very easy. When we split the entities, it becomes a little more complicated. Here is what our entities looked like after being split:

@Entity
@Table
public class Listing implements Serializable {
@Id
@GeneratedValue
private long id;
@Column(columnDefinition= "DECIMAL(10,2)")
private double price;
@OneToOne
@PrimaryKeyJoinColumn
private ListingLocation listingLocation;
...

and

@Entity
@Table
public class ListingLocation implements Serializable {
@Id
@Column(name = "listingID")
private Long id;
private String address;
...


The differences are not large, but there are a couple important points to note:

• Adding ListingLocation to Listing with @OneToOne & @PrimaryKeyJoinColumn annotations tells Hibernate the Listing has a one-to-one mapping with ListingLocation by using the Primary Key as the join column.
• Adding @Id & @Column(name = “listingID”) annotations to our id field in ListingLocation tells Hibernate that id is, well, an ID, but that column should not be called “id” in the DB, but “listingID” as that will help an observer see the relationship quickly without looking closely at the schema. Also, it is good to note that the @GeneratedValue is not on “id” in ListingLocation as it is in Listing as we want to specify exactly what goes in that field.

The biggest gripe I have with using the one-to-one relationship is that we can no longer save Listing only. Our REAL Listing entity is far more complex with several relationships, but this was the first one-to-one relationship with Hibernate. Previously we could do something like:

Listing listing = new Listing();
listing.setPrice(price);
listing.setAddress(address);
listing.setFoo(foo); // where foo is a @OneToMany annotated entity
...
session.save(listing);

Now, we must save Listing and ListingLocation separately like this:

ListingLocation listingLocation = new ListingLocation();
listingLocation.setAddress(address);
Listing listing = new Listing();
listing.setPrice(price);
listing.setListingLocation(listingLocation);
...
session.save(listing);
if (listing.getListingLocation() != null) {
listing.getListingLocation().setId(listing.getId());
session.save(listing.getListingLocation()); // save ListingLocation
}


I guess I’m just a bit spoiled, but I was hoping that this would bit more automatic, as it is with the one-to-many/many-to-one relationships.

I have written a small app that uses these two entities and inserts a row into each table, the link is available at the bottom of this post. The config (hibernate.cfg.xml) expects that you have MySQL running on 127.0.0.1 with a DB named ‘OneToOneDemo’ with a user named ‘root’ and a password of ‘password’; I have included the SQL (Setup-OneToOneDemo.sql) to setup the DB. Just extract the contents of the archive, navigate to the project directory, and from the command line/terminal run:

mvn clean compile exec:java -Dexec.mainClass=com.point2.onetoonedemo.App -e


You should see the following output:

@OneToOne @PrimaryKeyJoinColumn Hibernate Demo
----------------------------------------------
...
Hibernate:
insert into Listing (price) values (?)

Hibernate:
insert into ListingLocation (address, listingID) values (?, ?)
Saved listing ID: 1


Download Source Code (12 KB .ZIP)

If you have any questions, comments, or suggestions on how to do better accomplish one-to-one Hibernate mappings, I would love to hear about them. If you have any problems getting the code to compile and/or run, please let me know and I will make the necessary changes. Everything should just work, providing you modify the hibernate config or setup your DB. I had a difficult time finding complete and recent documentation on this subject so I hope this post and the maven project will help.

By: Damien Gabrielson


/*
FOREIGN KEY INDEX CREATOR

Primary key:-  The attribute or combination of attributes that uniquely identifies a row or record.

Foreign Key:- an attribute or combination of attribute in a table whose value match a primary key in another table.

Composite key:- A primary key that consistsof two or more attributes is known as composite key.

Candidate key:-  is a column in a table which has the ability to become a primary key.

Alternate Key:- Any of the candidate keys that is not part of the primary key is called an alternate key.

Many ABAPers gets confused initially with these tables. The difference lies in there Implementation and Behavior. Lets have a closer look at each to understand them better.

Value Table

 This is maintained at Domain Level.

In some cases you already know when you define a domain that all the fields referring to this domain should be checked against a certain table. This information can be stored in the domain by entering a value table.

 The system proposes the value table as check table when you try to define a foreign key for this field. You can override this proposal.

 Entering a value table does not implement a check. The check against the value table only takes place when a foreign key is defined.

 Check table

 Table whose key fields are used to check the foreign key fields (see Foreign Keys). Only entries that are contained in the key fields of the check table can be contained in the foreign key fields. 

Defining Check Table

The check table is used to check whether the input values are valid and for the input help (F4 help).

For example you have Employee master table & Employee Transaction table.

When ever an employee Transacts we need to check whether that employee exists , so we can refer to the employee master table. This is nothing but a Parent & Child relationship . Here data can be maintained at client level, no development involved.

 As per DBMS what we call Parent table, is called as check table in SAP.

Notable Difference

The contents of the check will be used as an input help(F4 Help) for a particular field on which a check table is assigned. But the contents of Value Table are never used in Input Help.

Foreign key is set in one-to-many relation.

For example,

Publisher – Book

—-

class Book(models.Model):

publisher = models.ForeignKey(Publisher)

—–

There are two cases:

>>> b = Book.objects.get(id=78)

>>>b.publisher

>>>p=Publisher.objects.get(name=’Aplus’)

>>>p.book_set.all()

Note that book_set

is just a QuerySet.

Thus it can be filtered and sliced.

>>>p.book_set.filter(name__icontains=’django’).order_by(‘name’)[0:2]

DBINST started to display the following error message:

ORA-00060: Deadlock detected. More info in file /u01/app/oracle/admin/DBINST/udump/DBINST_ora_1705.trc.

When the deadlocks occurred, the application was failing and logging errors too.

Oracle Concept Manual: “A deadlock can occur when two or more users are waiting for data locked by each other. Deadlocks prevent some transactions from continuing to work. … Oracle automatically detects deadlock situations and resolves them by rolling back one of the statements involved in the deadlock, thereby releasing one set of the conflicting row locks. “

The start of the trace files were similar to each other, so it appeared to be the same piece of code causing the problem:

DEADLOCK DETECTED
Current SQL statement for this session:
delete from PORTDETAIL where ID=:1 and version=:2
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TM-0000e7bc-00000000        28     132    SX   SSX       25     135    SX   SSX
TM-0000e7bc-00000000        25     135    SX   SSX       28     132    SX   SSX
session 132: DID 0001-001C-0000052F     session 135: DID 0001-0019-00000B29
session 135: DID 0001-0019-00000B29     session 132: DID 0001-001C-0000052F
Rows waited on:
Session 135: obj - rowid = 0000E7DC - AAAOfcAAFAAAAjIAAA
(dictionary objn - 59356, file - 5, block - 2248, slot - 0)
Session 132: obj - rowid = 0000E7DC - AAAOfcAAFAAAAjIAAA
(dictionary objn - 59356, file - 5, block - 2248, slot - 0)
Information on the OTHER waiting sessions:
Session 135:
pid=25 serial=1301 audsid=134658 user: 60/EGSCHEMA
O/S info: user: , term: , ospid: 1234, machine: dbserver.local
program:
Current SQL Statement:
delete from PORTDETAIL where ID=:1 and version=:2
End of information on OTHER waiting sessions.

I looked noticed that this was a bit different than other deadlocks I’ve seen; it was dead locking on table locks instead of row locks (transactions). This made me suspect a foreign key wasn’t indexed. (It could be the result of an application doing something unusual, like issuing lock table commands or DDL even).

So in this case we should ignore the “Rows waited on” section, which is useful when we have blocking transactions (TX).

I checked which table was locked:

TM=table lock (DML lock)
0×0000e7bc=59324

select owner, object_name from dba_objects where DATA_OBJECT_ID=59324;
OWNER
------------------------------
OBJECT_NAME
------------------------------
EGSCHEMA
PORTSERVICEORDER

Note that this isn’t the table in the SQL statement for either session: PORTDETAIL.

So, is there a trigger or a foreign key that could cause a lock on PORTSERVICEORDER when a row from PORTDETAIL is deleted?

@dd
EGSCHEMA
PORTDETAIL
TYPE              NAME                           OWNER                          'SOF 'REFERENCED'  NULL
----------------- ------------------------------ ------------------------------ ---- ------------- ------------------------------
INDEX             PD_PSO_IDX                     EGSCHEMA                       HARD ON_OBJECT
INDEX             PK_PORTDETAIL                  EGSCHEMA                       HARD ON_OBJECT
TABLE             PORTITEM                       EGSCHEMA                       HARD FK_REF_OBJECT FK_PORTITEM_PORTDETAIL
TABLE             PORTSERVICEORDER               EGSCHEMA                       HARD FK_REF_OBJECT FK_PSO_APPROVEDPORTDETAILS
TABLE             PORTSERVICEORDER               EGSCHEMA                       HARD FK_REF_OBJECT FK_PSO_GSPPORTDETAILS
VIEW              VIEW_GC_LC_FOR_COMPLETED_PORTS EGSCHEMA                       SOFT REFERENCED

Yes! Two foreign keys.

Are these foreign keys indexed?

@$DBA_SQLPATH/apt/missing_fk_indexes.sql
TABLE_NAME                                       COLUMN_NAME
------------------------------------------------ ------------------------------
EGSCHEMA.PORTSERVICEORDER                        APPROVEDPORTDETAILS
EGSCHEMA.PORTSERVICEORDER                        GSPPORTDETAILS

No, neither of them are indexed.

My Interpretation

A row is being updated or deleted from the child PORTSERVICEORDER, and then a row is deleted from the parent table PORTDETAIL in the same transaction. There is no index on the foreign key so a lock is taken on the whole PORTSERVICEORDER table. When two sessions attempt these same steps concurrently, they would deadlock because they both hold an SX (row exclusive) lock in PORTSERVICEORDER and both are asking for an SSX (share sub-exclusive) lock on PORTSERVICEORDER.

In general, foreign keys should be indexed unless the parent table has very little DML on it. So… I asked the developers to index these foreign keys and we haven’t had deadlocks since.

Key dalam Bahasa Indonesia berarti kunci, maka semakna dengan itu fungsi dari key-key yang berada pada sebuah database. Artinya setiap pintu pasti mempunyai kunci khusus untuk membukanya, begitu pula tabel dalam database. Key-key inilah yang membantu dalam pengolahan data pada sebuah tabel (insert, update, delete).

Secara global key-key dalam Oracle dapat dibagi sebagai berikut :

Setelah mengetahui definisi “mudah” dari setiap key maka ada beberapa tips yang harus diperhatikan dalam pemberian key pada kolom-kolom dalam sebuah tabel :

1. Pastikan sebuah tabel mempunyai primary key.
2. Pastikan primary key tersebut mewakili unique-nya sebuah record.
3. Ada baiknya menjadikan satu kolom saja untuk sebuah primary key sebagai autonumber mewakili beberapa kolom yang merupakan unique-nya record. Mis : tabel BELAJAR mempunyai tiga kolom sebagai primary key, yaitu : NIG, Kode_MP, dan Kelas_ID, maka ketiga kolom tersebut dapat dijadikan alternate key, dan untuk primary key-nya dibuatkan satu kolom lagi, yaitu Belajar_ID. Ini akan mempermudah jika ada tabel yang mengambil primary key pada tabel BELAJAR sebagai foreign key tabel tersebut.
4. Jangan terlalu banyak dalam pembuatan alternate key, karena key ini akan memperlambat proses insert dan update pada tabel tersebut. Secara logika alternate key akan mengecek ke-unique-kan seluruh record dari setiap record baru yang di-insert atau perubahan data pada record. Bayangkan jika datanya cukup besar… dan banyak alternate key… !!
5. Pilihlah dengan baik alternate key karena alternate key akan mempermudah dan mempercepat proses select jika digunakan. Maksudnyanya adalah KOLOM-KOLOM dalam alternate key tersebut yang digunakan.
6. Gunakan Non-unique key untuk kolom yang sering digunakan dalam proses select.
7. Gunakan penamaan key-key tersebut dengan penamaan yang baik dan mudah diidentifikasikan, seperti BELAJAR_PK (primary key tabel BELAJAR), BELAJAR#GURU_FK (foreign key pada tabel BELAJAR dari tabel GURU), dan BELAJAR_AK (alternate key tabel BELAJAR)

Untuk cara pembuatan key-key tersebut dapat dilihat dari contoh berikut :

Atau bisa ditulis dengan :

prblm: I have a parent child table pair, and trying to insert data into child table which exists in parent table. The datatype and length of field etc etc is exactly same. But still MySQL throws constriant violation error.

solution:Its not a universal solution as such, but please check if the constriant was created properly. If at the time of constraint creation FOREIGN_KEY_CHECKS was set to 0/false; the constraint definition would be stored in information_schema without evaluating if the table/column/schema names used even exists.

description:Though at first glance the behavior of not checking the schema name looks sinister, the very flag FOREIGN_KEY_CHECKS tells MySQL that constriants are not to be checked. This would simple use the table/constraint creation script to dump the definition in information_schema and would be used to evaluate the constraint when activated.

And as the MySQL error descriptions are as bad as they can be, whatever failure happens with data insertion in case of constraint evaluation is coined as constriant failure.

Jika kita membuat tabel dalam MySQL dengan enggine InnoDb, maka kita bisa menggunakan FOREIGN KEY Constrain. Salah satu manfaanya adalah, misalkan ada tabel induk A dan tabel anak B. Jika kita menghapus record dalam tabel induk A, maka dalam tabel B yang terdapat nilai dalam tabel A akan dihapus.Sintaksnya adalah seperti ini:

[CONSTRAINT symbol] FOREIGN KEY [id] (index_col_name, ...)
REFERENCES tbl_name (index_col_name, ...)
[ON DELETE {RESTRICT | CASCADE | SET NULL | NO ACTION}]
[ON UPDATE {RESTRICT | CASCADE | SET NULL | NO ACTION}]

Keterangan:

CASCADE: menghapus atau meng-update baris data dalam tabel induk secara otomatis atau mengupdate baris yang sesuai dalam tabel anak

SET NULL: menghapus atau meng-update baris data dalam tabel induk dan men-set kolom/beberapa kolom dalam tabel anak menjadi null. hal ini akan valid jika kolom foreign key tidak memiliki not null. kita boleh menggunakan ON DELETE SET NULL dan ON UPDAE

SET NULL jika kita gunakan SET NULL, pastikan bahwa anda tidak mendeklarasikan kolom dalam tabel anak dalam NOT NULL NO ACTION: dalam standar SQL, NO ACTION berarti tidak diprbolehkan menghapus, merubah nilai primary key jika ada foreign key yang berhubungan dalam tabel referensi. innodb menolak  untuk menghapus atau merubah data pada tabel induk

RESCRICT: tidak memperbolehkan menghapus atau merubah pada tabel induk. ini hampir sama sama dengan NO ACTION SET DEFAULT: aksi ini dibutuhkan oleh parser, tapi InnoDB menolak definisi tabel berupa ON DELETE SET DEFAULT atau ON DELETE SET DEFAULT klausa. OK, biar lebih jelas anda bisa mencoba beberapa percobaan berikut:

# buat database perpustakaan

CREATE DATABASE perpustakaan;

USE perpustakaan;

#buat tabel pengarang

create table pengarang (
id int(5) not null,
nama varchar(30) not null,
alamat varchar(50),
primary key(id)
) engine=innodb;

# buat tabel penerbit

create table penerbit(
id int(5) not null auto_increment,
nama varchar(30) not null,
alamat varchar(50),
primary key(id)
)engine=innodb;

# buat tabel buku

create table buku (
 id int(5) not null,
 id_penerbit int(5),
 id_pengarang int(5),
 isbn varchar(20),
 index (id_penerbit),
 foreign key (id_penerbit) references penerbit(id) on update cascade on delete restrict,
 index (id_pengarang),
 foreign key (id_pengarang) references pengarang(id)
 ) engine=innodb;

# masukkan data ke dalam tabel penerbit

insert into penerbit values(null, 'Intimedia', 'jakarta');
 insert into penerbit values(null, 'Tiara Wacana', 'Yogyakarta');
 insert into penerbit values(null, 'Diva Press', 'Yogyakarta');

# masukkan data ke dalam tabel pengarang

insert into pengarang values(1, 'Abdul kodir', 'Yogyakarta');
 insert into pengarang values(2, 'Salim A Fillah', 'Yogyakarta');
 insert into pengarang values(3, 'Fathan Funtastic', 'Yogyakarta');

Sekarang mari kita lakukan beberapa percobaan

# percobaan 1

insert into buku values(1,6,9,'12345');

Error yang akan muncul kurang lebih seperti ini: ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`learn_mysql`.`buku`, CONSTRAINT `buku_ibfk_1` FOREIGN KEY (`id_penerbit`) REFERENCES `penerbit` (`id`) ON UPDATE CASCADE) Mengapa demikian? Hal ini dikarenakan kita ingin mencoba memasukkan nilai id(id_pengarang, id_penerbit) yang didak ada di dalam tabel pengarang maupun tabel penerbit.

# percobaan 2

insert into buku values(1,2,1,'12345');

Kali ini tidak akan terjadi eror, hal ini karen nilai 2 dan 1 pada perintah di atas sudah terdaftar dalam kedua tabel induk: pengarang, penerbit cobalah untuk melihat isi tabel buku:

select * from buku;
+----+-------------+--------------+-------+
| id | id_penerbit | id_pengarang | isbn  |
+----+-------------+--------------+-------+
|  1 |           2 |            1 | 12345 |
+----+-------------+--------------+-------+

#percobaan 3

delete from penerbit where id=2;

eror yang akan muncul adalah: ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`learn_mysql`.`buku`, CONSTRAINT `buku_ibfk_1` FOREIGN KEY (`id_penerbit`) REFERENCES `penerbit` (`id`) ON UPDATE CASCADE) kenapa? karena kita mendefinisikan pada tabel buku bahwa id dari penerbit adalah ON DELETE RESTRICT,

# percobaan 4

update penerbit set id=7 where id=2;

kali ini tidak akan muncul eror tapi cobalah utuk melihat isi tabel buku berikut:

select * from buku;

+----+-------------+--------------+-------+
| id | id_penerbit | id_pengarang | isbn  |
+----+-------------+--------------+-------+
|  1 |           7 |            1 | 12345 |
+----+-------------+--------------+-------+

jika kita lihat, id_penerbit pada tabel buku juga akan berubah.

 1. Konversi Tipe database dari MyISAM ke InnoDB

2. Buat index dari field yang akan dijadikan foreign key

3. Kemudian pilih relation view arahkan field yg jadi index ke field tabel yg dijadikan Primary key.

Screenshoot gambar ntar nyusul.

IF EXISTS (SELECT * FROM sys.foreign_keys
WHERE object_id = OBJECT_ID(N’[dbo].[FK_Name]‘)
AND parent_object_id = OBJECT_ID(N’[dbo].[ChildTableName]‘))
ALTER TABLE [dbo].[ChildTableName]
DROP CONSTRAINT [FK_Name]
GO
————————————————————————–

ALTER TABLE [dbo].[ChildTableName] WITH CHECK ADD CONSTRAINT [FK_Name] FOREIGN KEY([FKIDName])
REFERENCES [dbo].[MasterTableName] ([MasterPKID])
GO
ALTER TABLE [dbo].[ChildTableName] CHECK CONSTRAINT [FK_Name]
GO

——————————————————————-

/*
Autor : Fausto Odilon
Data : 03/04/2009
Descrição:
Este Script demonstra uma falha de validação de Foreign Keys do SQL Server.
Quando uma Foreign Key é composta por mais de um campo com preenchimento opcional (NULL),
se um dos campos for informado como nulo, os demais não serão validados, permitindo
qualquer valor, ou seja, a inclusão de lixos na tabela relacionada.
*/

create table TMP_Teste_PK
(
Campo1 int NOT NULL,
Campo2 int NOT NULL,
Campo3 int NOT NULL,
CONSTRAINT PK_TMP_Teste_PK
PRIMARY KEY CLUSTERED (Campo1, Campo2, Campo3)
)

insert into TMP_Teste_PK
select 1, 1, 1
union select 1, 2, 1
union select 1, 3, 1
union select 2, 1, 2
union select 2, 2, 2
union select 3, 1, 2
union select 3, 2, 2

create table TMP_Teste_FK
(
Campo1 int NULL,
Campo2 int NULL,
Campo3 int NULL,
CONSTRAINT PK_TMP_Teste_FK
foreign KEY (Campo1, Campo2, Campo3)
references TMP_Teste_PK (Campo1, Campo2, Campo3)
)

truncate table TMP_Teste_FK
insert into TMP_Teste_FK
select 1, 1, 1 — Dados OK
union select 1, 2, 1 — Dados OK
union select 2, 2, 2 — Dados OK
union select 2, NULL, 1 — Dados Inválidos
union select 5, NULL, 2 — Dados Inválidos
union select -99, NULL, 3 — Dados Inválidos
union select NULL, 98, -17 — Dados Inválidos

select * from TMP_Teste_FK

drop table TMP_Teste_FK
drop table TMP_Teste_PK

Olá, pessoal

Na última semana surgiu uma pergunta na lista pgbr-geral sobre como descobrir a definição das restrições (constraints) de chave primária (primary key) e chave estrangeira (foreign key). Então aproveito para escrever um pouquinho sobre o assunto.

Essa informação não é encontrada diretamente nas tabelas e visões do catálogo do PostgreSQL, mas sim através de uma função chamada pg_get_constraintdef(oid), onde o parâmetro oid é o oid da constraint e que pode ser encontrado na tabela pg_constraint. Por exemplo, existe uma visão chamada pg_indexes que mostra as definições dos índices, porém se pararmos para analisar esta consulta veremos que para apresentar a definição dos índices é utilizada uma função chamada pg_get_indexdef(oid) semelhante a função usada para extrair a definição das restrições (constraints).

Abaixo segue a consulta para identificar o nome da tabela e suas definições de chave primária (primary key) e chave estrangeira (foreing key). Para encontrar essa informação é necessário o uso das tabelas de sistema pg_class e pg_constraint. Coloquei também a tabela pg_namespace que é onde são armazenados os esquemas existentes do PostgreSQL.

SELECT pg_class.relname AS nome_da_tabela,

pg_get_constraintdef(pg_constraint.oid) AS definicao_da_restricao

FROM pg_namespace JOIN pg_class ON pg_namespace.oid=pg_class.relnamespace

JOIN pg_constraint ON pg_class.oid=pg_constraint.conrelid

WHERE pg_namespace.nspname=’public’

AND pg_class.relkind=’r’

ORDER BY pg_class.relname;

O resultado desta consulta apresenta o nome da tabela e a sua respectiva definição de chave primária (primary key) e chave estrangeira (foreign key). Caso a tabela não possua chave primária e/ou chave estrangeira a mesma não será retornada por esta consulta. Neste caso seria necessário substituir o INNER JOIN por um LEFT OUTER JOIN. A palavra OUTER no LEFT OUTER JOIN é opcional.

E a sua implementação ficaria assim:

SELECT pg_class.relname AS nome_da_tabela,

pg_get_constraintdef(pg_constraint.oid) AS definicao_da_restricao

FROM pg_namespace JOIN pg_class ON pg_namespace.oid=pg_class.relnamespace

LEFT OUTER JOIN pg_constraint ON pg_class.oid=pg_constraint.conrelid

WHERE pg_namespace.nspname=’public’

AND pg_class.relkind=’r’

ORDER BY pg_class.relname;

Na cláusula WHERE existem duas restrições: pg_namespace.nspname=’public’ restringe em qual esquema serão procurados os objetos, neste caso apenas no esquema public. Se for necessário procurar em mais de um esquema pode-se substituir a condição pg_namespace.nspname=’public’ por pg_namespace.nspname IN (‘public’, ‘outro_esquema’). A condição pg_class.relkind=’r’ restringe que só serão pesquisados os objetos do tipo tabela. Esta restrição é importante pois a tabela pg_class armazena outros objetos como: índices, seqüências, visões, tipos compostos e tabelas toast. Esta condição é necessária devido ao join com a tabela pg_namespace. Se essa junção for retirada não é necessária esta restrição.

Se for de interesse é possível mostrar o nome da restrição (constraint) através do atributo conname que está armazenado na tabela pg_constraint.

Era isso. Fiquem a vontade para comentários.

Abraços

Olá Pessoal,

Hoje estaremos abordando a criação de uma tabela com chave estrangeira ou foreign key.

Abordaremos então:

- O que é uma chave estrangeira(FK)?

- Colocando em prática

- Por que usar?

Bom pra começar chave estrangeira ou foreign key, é a relação entre duas tabelas tendo na tabela “mãe” a referência da tabela “filho”.

Ficou confuso?

vamos exemplificar, todos nós sabemos que um cliente precisa morar em uma cidade, então temos a tabela “mãe” que é a Cliente, onde nos atributos tem a referência da tabela filho que é a Cidade, conforme mostro a seguir:

Cliente Cidade

( (

ClienteId(PK) CidadeId(PK)

Nome Cidade

Endereco Estado

Telefone )

CidadeId(FK)

)

reparem que coloquei uma coluna chamada CidadeId, o que é essa CidadeId? Nada mais é que a chave primaria da tabela Cidade e a chave estrangeira da tabela Clientes.

Pois na hora de inserir registros na tabela de Clientes, ao invés de inserirmos Campinas, Vinhedo, Valinhos, nós armazenaremos a referência delas na tabela de Cidade.

CidadeId Cidade Estado

1 Campinas SP

2 Valinhos SP

3 Vinhedo SP

Na tabela de Cliente só iremos armazenar 1,2 ou 3, que são os registros existentes na tabela de Cidade, caso um “engraçadinho” tente inserir um 4 por exemplo, sem que ele esteja na tabela de Cidade dará um erro de chave estrangeira, não sendo possível a gravação.

Agora entendi, mas como crio uma chave estrangeira?

Simples, iremos criar as tabelas Cliente e Cidade primeiro. Uma boa prática para criação de tabelas, é sempre começar pelas tabelas simples, ou seja, aquelas que não possuem chave estrangeira.

CREATE TABLE Cidade

(

CidadeId int not null IDENTITY(1,1),

Cidade nvarchar(64) not null CONSTRAINT UQ_Cidade_Cidade UNIQUE,

Estado char(2) not null,

CONSTRAINT PK_Cidade_CidadeId PRIMARY KEY(CidadeId)

)

CREATE TABLE Cliente

(

ClienteId int not null IDENTITY(1,1),

Nome nvarchar(128) not null,

Endereco nvarchar(128) not null,

CidadeId int not null,

CONSTRAINT PK_Cidade_ClienteId PRIMARY KEY(ClienteId),

CONSTRAINT FK_Cliente_Cidade_CidadeId FOREIGN KEY(CidadeId) REFERENCES Cidade(CidadeId)

)

Repare que na tabela Cliente, eu crio a chave estrangeira, mas esse não é o único jeito de criar. Poderiamos ter criado as tabelas Cliente/Cidade, e depois usar a keyword ALTER TABLE para estar adicionando a chave, conforme mostro abaixo:

ALTER TABLE Cliente

ADD CONSTRAINT FK_Cliente_Cidade_CidadeId

FOREIGN KEY(CidadeId)

REFERENCES Cidade(CidadeId)

Bom, já entendi o que é, já criei a chave, mas por que utiliza-la?

Pois bem, utilizamos ela para:

* Manter a concistência do banco de dados

* Para criação de indices, na qual estaremos vendo adiante.

* Para otimização do banco de dados.

* Para facilitar a manutenção.

Pessoal, por hoje é só, quem tiver dúvidas no assunto, pode comentar que eu respondo ou ainda me mandar e-mail: marcelinho.ruliz@gmail.com

Abraço,

Té mais.

This article comes to us from Tim Young. Tim writes "One of the (few) very handy things about Access is the cascade delete function. If you delete a record from a parent table, all relating records in the child tables are also deleted. I couldn’t find any way of doing this in SQL Server 7, so I wrote a stored procedure for it." Thanks for the article Tim!

Normally, if you try and delete a record from a table that is constrained by a foreign key, you’ll get an error message. This procedure checks for any foreign keys for the table, deletes any child records, then deletes the intended record.

It references the system tables sysforeignkeys, sysobjects and syscolumns. Sysforeignkeys does what it says on the tin – it’s a list of all foreign keys in the database. It doesn’t contain actual table and field names, instead it contains links to the sysobjects (tables, stored procedures, views etc) and syscolumns (fields).

The procedure works like this – if we want to delete a record from table X, we look in the sysforeignkeys table for all references where table X is the parent table. It may be involved in several such FK’s. All we do is recursively go through these FK’s, deleting the child table records that are linked to the record we want to delete.

For example,

- delete all records from table X where field1 equals ‘234′

- table Y is linked to X through the Y_ID field, so

- table Z is linked to Y through the Z_ref field

As you can see from the above example, if one of the child tables is also involved in a FK constraint, we also need to delete the relating rows in it’s child tables.

Here’s the code for the procedure:

CREATE Procedure spDeleteRows

/*

Recursive row delete procedure.



It deletes all rows in the table specified that 

conform to the criteria selected,



while also deleting any child/grandchild records and 

so on.  This is designed to do the



same sort of thing as Access's cascade delete function. 

It first reads the sysforeignkeys



table to find any child tables, then deletes the 

soon-to-be orphan records from them using



recursive calls to this procedure. Once all 

child records are gone, the rows are deleted



from the selected table.   It is designed at this 

time to be run at the command line. It could



also be used in code, but the printed output 

will not be available.


*/

	(


	@cTableName varchar(50), /* name of the table where 

                                 rows are to be deleted */



	@cCriteria nvarchar(1000), /* criteria used to 

                                             delete the rows required */



	@iRowsAffected int OUTPUT /* number of records 

                                        affected by the delete */


	)

As

set nocount on

declare 	@cTab varchar(255), /* name of the child table */

	@cCol varchar(255), /* name of the linking field on the child table */

	@cRefTab varchar(255), /* name of the parent table */


	@cRefCol varchar(255), /* name of the linking field in the 

                                   parent table */


	@cFKName varchar(255), /* name of the foreign key */


	@cSQL nvarchar(1000), /* query string passed to the sp_ExecuteSQL 

                                     procedure */


	@cChildCriteria nvarchar(1000), /* criteria to be used to delete

                                           records from the child table */

	@iChildRows int /* number of rows deleted from the child table */


/* declare the cursor containing the foreign key constraint information */

DECLARE cFKey CURSOR LOCAL FOR

SELECT SO1.name AS Tab,

       SC1.name AS Col,

       SO2.name AS RefTab,

       SC2.name AS RefCol,

       FO.name AS FKName

FROM dbo.sysforeignkeys FK

INNER JOIN dbo.syscolumns SC1 ON FK.fkeyid = SC1.id

                              AND FK.fkey = SC1.colid

INNER JOIN dbo.syscolumns SC2 ON FK.rkeyid = SC2.id

                              AND FK.rkey = SC2.colid

INNER JOIN dbo.sysobjects SO1 ON FK.fkeyid = SO1.id

INNER JOIN dbo.sysobjects SO2 ON FK.rkeyid = SO2.id

INNER JOIN dbo.sysobjects FO ON FK.constid = FO.id

WHERE SO2.Name = @cTableName


OPEN cFKey

FETCH NEXT FROM cFKey INTO @cTab, @cCol, @cRefTab, @cRefCol, @cFKName

WHILE @@FETCH_STATUS = 0

     BEGIN


	/* build the criteria to delete rows from the child table. 

           As it uses the

           criteria passed to this procedure, it gets progressively larger with

           recursive calls */


	SET @cChildCriteria = @cCol + ' in (SELECT [' + 

                               @cRefCol + '] FROM [' +

 

                              @cRefTab +'] WHERE ' + @cCriteria + ')'

	print 'Deleting records from table ' + @cTab

	/* call this procedure to delete the child rows */

	EXEC spDeleteRows @cTab, @cChildCriteria, @iChildRows OUTPUT

	FETCH NEXT FROM cFKey INTO @cTab, @cCol, @cRefTab, @cRefCol, @cFKName

     END

Close cFKey

DeAllocate cFKey

/* finally delete the rows from this table and display the rows affected  */

SET @cSQL = 'DELETE FROM [' + @cTableName + '] WHERE ' + @cCriteria

print @cSQL

EXEC sp_ExecuteSQL @cSQL


print 'Deleted ' + CONVERT(varchar, @@ROWCOUNT) +

 ' records from table ' + @cTableName

In the above scenario, we were trying to perform the following :

Using this procedure, we would use the following command:

I hope this procedure has been of use.

Source: http://www.sqlteam.com/article/performing-a-cascade-delete-in-sql-server-7

All data are represented as tables.

o The results of any given query are just another table!
Tables are comprised of rows and columns
Rows and columns are (officially) unordered (i.e., the order in which rows and columns are referenced does not matter).

o Rows are sorted only upon request. Otherwise, their order is arbitrary, and may change for a dynamic database

o Column order is determined by each query
Each table has a primary key, a unique identifier constructed from one or more columns

Most primary keys are a single column (e.g., TOWN_ID)
A table is linked (joined) to another by including the other table’s primary key. Such an included column is called a foreign key. Primary keys and foreign keys are the most important concepts in database design.

Relational database components include:

• Table
• Row
• Column
• Field
• Primary key
• Foreign key

A Table is a basic storage structure of an RDBMS and consists of columns and rows. A table represents an entity. For example, the S_DEPT table stores information about the departments of an organization.

A Row is a combination of column values in a table and is identified by a primary key. Rows are also known as records. For example, a row in the table S_DEPT contains information about one department.

A Column is a collection of one type of data in a table. Columns represent the attributes of an object. Each column has a column name and contains values that are bound by the same type and size. For example, a column in the table S_DEPT specifies the names of the departments in the organization.

A Field is an intersection of a row and a column. A field contains one data value. If there is no data in the field, the field is said to contain a NULL value.

A Primary key is a column or a combination of columns that is used to uniquely identify each row in a table. For example, the column containing department numbers in the S_DEPT table is created as a primary key and therefore every department number is different. A primary key must contain a value. It cannot contain a NULL value.

A Foreign key is a column or set of columns that refers to a primary key in the same table or another table. You use foreign keys to establish principle connections between, or within, tables. A foreign key must either match a primary key or else be NULL. Rows are connected logically when required. The logical connections are based upon conditions that define a relationship between corresponding values, typically between a primary key and a matching foreign key. This relational method of linking provides great flexibility as it is independent of physical links between records.

WordPress Tags: DBMS,Relational Model,Model,database,Column,Primary Key,Table,Field,Foreign Key,RDBMS,relationship,columns

O MySQL as vezes nos surpreende, devido ao fato de alguns comandos SQL ANSI não funcionarem nele, como é o caso do drop constraint para exclusão de chaves estrangeiras, as foreign keys.

O comando padrão, que funciona em vários bancos (Firebird, SQL Server e outros) é alter  table NomeDaTabela drop constraint NomeDaConstraint;

Porém, não funciona no MySQL. O comando que deve ser executado é alter  table NomeDaTabela drop foreign key NomeDaConstraint;

Se você criou uma constaint sem um nome, o sistema InnoDB do MySQL gera um automaticamente. Para saber qual o nome gerado execute show create table NomeDaTabela; Este comando mostra a estrutura da tabela, com as constraints existentes e seus respectivos nomes. Daí, basta executar alter  table NomeDaTabela drop foreign key NomeDaConstraint; para apagar a foreign key desejada.

Referência: MySQL 5.1 Reference Manual

If you’re a frequent user of MySQL, you may be familiar with the fact that all MySQL table constraints automatically create indexes for you.  This is true of the InnoDB foreign key constraints, for which “an index is created on the referencing table automatically if it does not exist.”

If you’re switching or considering a switch to PostgreSQL, you should be aware that not all PostgreSQL table constraints will automatically create indexes for for you.  In PostgreSQL, a UNIQUE or PRIMARY KEY constraint on one or more fields will implicitly create an index for you.  However, in PostgreSQL a FOREIGN KEY constraint will not automatically create an index for you.

For each of your foreign key constraints, you should evaluate whether you want to create an index.  You may want to do this for optimizing your own queries, but be aware that it can also help to speed up DELETE queries on the referenced table and UPDATE queries on the referenced field.  This is because any foreign key reference must be located to enforce whatever ON DELETE and ON UPDATE behavior is in effect for the constraint.

FOREIGN KEYs

So I created also the foreign key successfully and now I’m wondering why the MATCH FULL foreign key is created when product_type field is NULL. Should the DBMS prevent such foreign key creation?
Well, the manual says this:

“The null matching on foreign keys is limited to the simple match type (null values satisfy the constraint). The full and partial match types are not supported. The referential action is currently limited to restrict, i.e. an update fails if other columns have references to it.”

http://monetdb.cwi.nl/projects/monetdb/SQL/Documentation/Table-Definition.html#Table-Definition

Like when I create these tables:

CREATE TABLE entity (
id INTEGER,
name CHAR(5),
PRIMARY KEY (id, name)
);

CREATE TABLE sub_entity (
id INTEGER,
name VARCHAR(10),
entity_id INTEGER,
entity_name CHAR(5),
PRIMARY KEY (id),
FOREIGN KEY (entity_id, entity_name) REFERENCES entity (id, name) MATCH FULL
);

And do these insertions:

INSERT INTO entity VALUES (1,'ABCDE');
INSERT INTO sub_entity VALUES (3,'sub3',NULL,'ABCDE');
INSERT INTO sub_entity VALUES (1,'sub1',NULL,NULL);

The foreign key’s MATCH FULL does not prevent the insertion of NULL into one or both of the table’s foreign key columns.

The cascading works as follows:
I add cascading (other than restrict) into the foreign key:

ALTER TABLE sub_entity ADD FOREIGN KEY (entity_id,entity_name) REFERENCES entity (id,name)
ON DELETE CASCADE ON UPDATE CASCADE;

Then I’ll update id column of entity table:

UPDATE entity
SET id = 2
WHERE id = 1;

The cascading is not done into sub_entity table, but no integrity constraint violations is given. That update works because there is in sub_entity table only (1, NULL) or (NULL, ‘ABCDE’) value pairs in entity_id and entity_name columns so the foreign key does not work even partially because SIMPLE match is only implemented.

So when no NULLs and wrong entity_id (or wrong entity_name) then the foreign key constraint works and this gives an error:

INSERT INTO sub_entity VALUES (11,'sub2',1,'ABCDE');

I vincoli interrelazionali più diffusi e significativi so i vincoli di integrità referenziale. In SQL per la loro definizione si usa l’apposito vincolo di foreign key, ovvero chiave esterna. Questo vincolo crea un legame tra i valori di un attributo della tabella su cui è definito (Tabella interna) e i valori di un’attributo di un’altra tabbella (Tabella esterna). Il vincolo impone che per ogni riga della tabella il valore dell’attributo specificate, se diverso dal valore nullo, sia presente nelle righe ella tabella esterna tra i valori del corrispondente attributo. L’unico requisito che la tabella impone è il vincolo unique in fatti tipicamente l’attributo della tabella esterna cui si fa riferimento rappresenta in effetti la chiave primaria della tabella. Se c’è un solo attributo coinvolto si può usare il costrutto sintattico references, con il quale si specifica che la tabella esterna e l’attributo della tabella esterna al quale l’attributo in questione deve essere legato.
Es:

create table Impiegato (
Matricola char ( 6 ) primary key,
Nome varchar ( 20 ) not null,
Cognome varchar ( 20 ) not null,
Dipart varchar ( 15 )
reference Dipartimento ( NomeDip ),
Ufficio numeric ( 13 ),
Stipendio numeric ( 9 ) default 0,
unique ( Cognome, Nome )
)

Il vincolo impone che l’attributo Dipart della tabella Impiegato possa assumere solo uno dei valori che le riche della tabella Dipartimento possiedono per l’attributo NomeDip.

Quando il legame invece è rappresentato da un’insieme di attributi, fa uso invece del costrutto foreign key, posto al termine della definizione degli attributi.
Es: Se si volesse prendere la tabella di prima e imporre che gli attributi Nome e Cognome debbano comparire in una tabella anagrafica, si potrebbe aggiungere il vincolo

foreing key ( Nome, Cognome )
reference Anagrafica ( Nome , Cognome )