Dúvidas, dicas e truques de PL/SQL. Aqui também vão assuntos relacionados a pacotes, triggers, funções, Java-Stored Procedures, etc

Poston Wed, 12 Apr 2006 11:16 am

Guys, I'm " mascotinho " vocês ...
But I also intend to be a consultant in the future.
I'm boarding with everything.
At first I would like to explain me vocês more simply about:-primary key and foreign key-packaging-interface and I really want to know about in the context of domain database..
Love you guys in oracle.
I Await.
Last edited by stcoutinho on Sat, 11 Jan 2014 1:56 pm, edited 1 time in total.
Reason: Editado inicialmente em letras maiusculas .. formatei o texto (minisculas) para faciliar leitura ..
rodrigo vasconcelos
Location: rio verde/go


Poston Sat, 11 Jan 2014 2:23 pm

Rodrigo, I'm answering this old topic open, in case any of forista ADDS encountering any questions like that.

I don't understand exactly what you mean, " " and " " domain interface, but about constraints (restrictions) of PK (primary key-primary key) and FK (foreign key), I can contribute with some information.

In relational databases in General (can be MYSQL, ORACLE, DB2, SQLSERVER, SYBASE, etc), there are database objects called CONSTRAINTS (restrictions), which aims to ensure the integrity of information stored in Bank.

Let's imagine the situation of a GROCERY RECEIPT. You note, when viewing the same, that it is composed of a header (where the data are recorded in the store and the consumer) and items (where are related products purchased).

Greatly simplifying the concepts of data modeling, you could create two tables " " composed of the following columns:
for purposes of taxation, the store may issue a single tax coupon number " ". In this case, to ensure that the TB_NOTA_FISCAL table to store only one record with this coupon number " " tax, you must create a PK in this table composed of column NU_NOTA_FISCAL ".

As I'm storing the data of an invoice in two separate tables, I need something that " tie " this information between the two tables so that the data of a note not to meld with the items of another note. We must also avoid that orphan invoices are created, IE, can never have the invoice ITEMS without your HEADER.

In this case, I end up creating a FK in table TB_NOTA_FISCAL_ITEM, composed of the NU_NOTA_FISCAL column, which points to the PK of the table TB_NOTA_FISCAL.

When I create this relationship between the tables, where TB_NOTA_FISCAL is the father and daughter TB_NOTA_FISCAL_ITEM, I am guaranteeing the integrity between the two tables. Also I chose to create a composite PK " " in TB_NOTA_FISCAL_ITEM.

The explanation that you spent is well simplified and I'm sure other foristas of ADDS would explain more didactic/correct my attempted now.

Perhaps most importantly to abstract this information is that a database is not simply a data warehouse " ', whose integrity is guaranteed only by the application. If in the future to work with database, try to make the most of these features of integrity that the Bank offers, because more " free " or " simple " it to be.

The huge advantage that you have to insert in the database integrity is that these rules are not lost and validate real-time information you are trying to store. When you place this validation only on the shoulders of the application, there are a number of factors that can conspire to compromise the integrity of your database. Examples: application that suffers incorrect maintenance and that fail to validate temporarily the data to be inserted, people entering data manually on the basis that do not respect the rules of business, etc.

An overview of database concepts can be found in this link from WIKIPEDIA: hugs and good studies, Sergio Coutinho
Location: Sao Paulo - SP

Return to PL/SQL

Who is online

Users browsing this forum: No registered users and 6 guests