Herencia

Para comprender ste concepto muy interesante y til para muchos casos hacer uso del
siguiente ejemplo bastante sencillo.

Crear una tabla llamada ciudades y otras capitales.

Las capitales son tambin ciudades pero supongamos que se necesita recuperar
rpidamente los datos de las ciudades, sin pasar por un ndice de tabla que
contiene miles o millones de registros. Esta es la mayor virtud de las tablas
heredades, si la usamos en los contextos correctos se puede mejorar el rendimiento
de una BD altamente concurrida que comience a sufrir de bloqueos y retrasos
importantes en el tiempo de lectura/escritura.
CREATE TABLE ciudades (
nombre
text,
poblacion
float,
altura
int );

Ya se tiene la tabla padre, a partir de este momento se puede crear un hijo a partir
de l. Adems se va agregar 1 columna ms que indicara el departamento o estado
que pertenece a sa capital.
CREATE TABLE capitales (
departamento char(2)
) INHERITS (ciudades);

Ahora se procede a insertar los datos en las respectivas tablas

Tabla ciudades
insert into ciudades values ('Fernando de la Mora', 24522, 25);
insert into ciudades values ('Lambar', 34500, 135);
insert into ciudades values ('San Lorenzo', 16852, 120);

Tabla capitales
insert into capitales values ('Asuncion', 450000, 136, 'CN');
insert into capitales values ('Encarnacion', 128000, 120, 'EN');

Con esto se obtiene una reduccin en la construccin del ndice y ganaremos velocidad con
ello adems de un mejor orden conceptual de las tablas.
No slo se puede heredar de un padre, es posible heredar de varias tablas, as teniendo la
tabla hija todas las columnas de sus padres, y en caso que 2 o ms padres tengan un

columna con el mismo nombre stas se fusionarn en la hija siempre y cuando sean del
mismo tipo de dato.
Al utilizar sta poderosa caracterstica existen algunas consideraciones que hay que tener
en cuenta para evitarnos sorpresas desagradables e inesperadas.

Al crear tablas heredadas, no todas las caractersticas de la tabla se heredan. Por

ejemplo, las claves primarias, forneas, ndices nicos. Segn el roadmap se ver
para implementarlo a futuro pero no es de prioridad alta por eso que
viene retrasndose su implementacin desde versiones antiguas..

http://www.devtroce.com/2010/11/14/herencia-de-tablas-en-postgresql/

Herencia
La herencia es un concepto de bases de datos orientadas a objetos que abre nuevas
posibilidades interesantes de diseo de bases de datos.
Crear dos tablas: una tabla de ciudades (cities) y otra tabla de capitales (capitals).
Naturalmente, las capitales tambin son ciudades, as que uno quisiera tener cierta forma
de mostrar las capitales de manera implcita cuando se listan las ciudades. Si uno es
realmente inteligente inventara un esquema como este:
CREATE TABLE
name
population
altitude
state
);

capitals (
text,
real,
int,
-- (en pies)
char(2)

CREATE TABLE
name
population
altitude
);

non_capitals (
text,
real,
int
-- (en pies)

CREATE VIEW cities AS

SELECT name, population, altitude FROM capitals
UNION
SELECT name, population, altitude FROM non_capitals;

Esto funciona bien para las consultas, pero se va poniendo feo cuando se necesita
actualizar varias filas.
Una mejor solucin es esta:
CREATE TABLE
name
population
altitude
);

cities (
text,
real,
int
-- (en pies)

CREATE TABLE capitals (

state
char(2)
) INHERITS (cities);

En este caso, una fila de capitals hereda todas las columnas de su tabla madre, cities
(name, population y altitude). El tipo de dato de la columna name es text, que es un tipo
de dato nativo de PostgreSQL para cadenas de letras de longitud variable. Las capitales
de estado tienen una columna adicional, state, que muestra su estado. En PostgreSQL,
una tabla puede heredar de cero o ms tablas.
Por ejemplo, la siguiente consulta encuentra el nombre de todas las ciudades, incluyendo
las capitales, que estn ubicadas a una altitud superior a los 500 pies:
SELECT name, altitude
FROM cities
WHERE altitude > 500;

Resultado:
name
| altitude
-----------+---------Las Vegas |
2174
Mariposa |
1953
Madison
|
845
(3 rows)

Por otro lado, la siguiente consulta encuentra todas las ciudades que no son capitales de
estado y que estn situadas a una altitud igual o superior a 500 pies:
SELECT name, altitude
FROM ONLY cities
WHERE altitude > 500;
name
| altitude
-----------+---------Las Vegas |
2174
Mariposa |
1953
(2 rows)

Aqu, el ONLY antes de cities indica que la consulta debe ejecutarse solamente sobre la tabla de
ciudades y no sobre las tablas que estn debajo de ella en la jerarqua de herencia. Muchas de las
rdenes que ya se han mencionado (SELECT, UPDATE y DELETE) admiten la notacin ONLY.
http://pgsqltutorial.readthedocs.org/en/latest/part_iii/inheritance.html

Las 12 reglas de Codd son un sistema de reglas propuestas por Edgar F. Codd, del modelo relacional
para las bases de datos, diseado para definir qu requiere un sistema de administracin de base de
datos.1
Codd se percat de que existan bases de datos en el mercado las cuales decan ser relacionales, pero lo
nico que hacan era guardar la informacin en las tablas, sin estar estas tablas literalmente
normalizadas; entonces ste public 12 reglas que un verdadero sistema relacional debera tener
aunque en la prctica algunas de ellas son difciles de realizar. Un sistema podr considerarse "ms
relacional" cuanto ms siga estas reglas.

Regla 0: el sistema debe ser relacional, base de datos y administrador de sistema.

Ese sistema debe utilizar sus facilidades relacionales (exclusivamente) para
manejar la base de datos.
Regla 1: la regla de la informacin, toda la informacin en la base de datos es
representada unidireccionalmente, por valores en posiciones de las columnas
dentro de filas de tablas. Toda la informacin en una base de datos relacional se
representa explcitamente en el nivel lgico exactamente de una manera: con
valores en tablas.
Regla 2: la regla del acceso garantizado, todos los datos deben ser accesibles sin
ambigedad. Esta regla es esencialmente una nueva exposicin del requisito
fundamental para las llaves primarias. Dice que cada valor escalar individual en la
base de datos debe ser lgicamente direccionable especificando el nombre de la
tabla, la columna que lo contiene y la llave primaria.

Regla 3: tratamiento sistemtico de valores nulos, el sistema de gestin de base

de datos debe permitir que haya campos nulos. Debe tener una representacin de
la "informacin que falta y de la informacin inaplicable" que es sistemtica,
distinto de todos los valores regulares.

Regla 4: catlogo dinmico en lnea basado en el modelo relacional, el sistema

debe soportar un catlogo en lnea, el catlogo relacional debe ser accesible a los
usuarios autorizados. Es decir, los usuarios deben poder tener acceso a la
estructura de la base de datos (catlogo).

Regla 5: la regla comprensiva del sublenguaje de los datos, el sistema debe

soportar por lo menos un lenguaje relacional que:
1. Tenga una sintaxis lineal.
2. Puede ser utilizado de manera interactiva.
3. Soporte operaciones de definicin de datos, operaciones de manipulacin
de datos (actualizacin as como la recuperacin), seguridad e integridad y
operaciones de administracin de transacciones.

Regla 6: regla de actualizacin, todas las vistas que son tericamente

actualizables deben ser actualizables por el sistema.

Regla 7: alto nivel de insercin, actualizacin, y cancelacin, el sistema debe

soportar suministrar datos en el mismo tiempo que se inserte, actualiza o est
borrando. Esto significa que los datos se pueden recuperar de una base de datos
relacional en los sistemas construidos de datos de filas mltiples y/o de tablas
mltiples.

Regla 8: independencia fsica de los datos, los programas de aplicacin y

actividades del terminal permanecen inalterados a nivel lgico cuando quiera que
se realicen cambios en las representaciones de almacenamiento o mtodos de
acceso.

Regla 9: independencia lgica de los datos, los cambios al nivel lgico (tablas,
columnas, filas, etc.) no deben requerir un cambio a una solicitud basada en la
estructura. La independencia de datos lgica es ms difcil de lograr que la
independencia fsica de datos.

Regla 10: independencia de la integridad, las limitaciones de la integridad se

deben especificar por separado de los programas de la aplicacin y se almacenan
en la base de datos. Debe ser posible cambiar esas limitaciones sin afectar
innecesariamente las aplicaciones existentes.

Regla 11: independencia de la distribucin, la distribucin de las porciones de la

base de datos a las varias localizaciones debe ser invisible a los usuarios de la
base de datos. Los usos existentes deben continuar funcionando con xito:
1. cuando una versin distribuida del SGBD se introdujo por primera vez
2. cuando se distribuyen los datos existentes se redistribuyen en todo el
sistema.

Regla 12: la regla de la no subversin, si el sistema proporciona una interfaz de

bajo nivel de registro, a parte de una interfaz relacional, que esa interfaz de bajo
nivel no se pueda utilizar para subvertir el sistema, por ejemplo: sin pasar por
seguridad relacional o limitacin de integridad. Esto es debido a que existen
sistemas anteriormente no relacionales que aadieron una interfaz relacional, pero
con la interfaz nativa existe la posibilidad de trabajar no relacionalmente.

http://es.wikipedia.org/wiki/12_reglas_de_Codd

Herencia
La herencia es un concepto de bases de datos orientadas a objetos que abre nuevas posibilidades
interesantes de diseo de bases de datos.
Creemos dos tablas: una tabla de ciudades (cities) y otra tabla de capitales (capitals).
Naturalmente, las capitales tambin son ciudades, as que uno quisiera tener cierta forma de mostrar las
capitales de manera implcita cuando se listan las ciudades. Si uno es realmente inteligente inventara
un esquema como este:
CREATE TABLE
name
population
altitude
state
);

capitals (
text,
real,
int,
-- (en pies)
char(2)

CREATE TABLE
name
population
altitude
);

non_capitals (
text,
real,
int
-- (en pies)

CREATE VIEW cities AS

SELECT name, population, altitude FROM capitals
UNION
SELECT name, population, altitude FROM non_capitals;

Esto funciona bien para las consultas, pero se va poniendo feo cuando se necesita actualizar varias
filas.
Una mejor solucin es esta:
CREATE TABLE
name
population
altitude
);

cities (
text,
real,
int
-- (en pies)

CREATE TABLE capitals (

state
char(2)
) INHERITS (cities);

En este caso, una fila de capitals hereda todas las columnas de su tabla madre, cities (name,
population y altitude). El tipo de dato de la columna name es text, que es un tipo de dato nativo de
PostgreSQL para cadenas de letras de longitud variable. Las capitales de estado tienen una columna
adicional, state, que muestra su estado. En PostgreSQL, una tabla puede heredar de cero o ms
tablas.
Por ejemplo, la siguiente consulta encuentra el nombre de todas las ciudades, incluyendo las capitales,
que estn ubicadas a una altitud superior a los 500 pies:
SELECT name, altitude
FROM cities
WHERE altitude > 500;

Resultado:
name
| altitude
-----------+---------Las Vegas |
2174
Mariposa |
1953
Madison
|
845
(3 rows)

Por otro lado, la siguiente consulta encuentra todas las ciudades que no son capitales de estado y que
estn situadas a una altitud igual o superior a 500 pies:
SELECT name, altitude
FROM ONLY cities
WHERE altitude > 500;
name
| altitude
-----------+---------Las Vegas |
2174
Mariposa |
1953
(2 rows)

Aqu, el ONLY antes de cities indica que la consulta debe ejecutarse solamente sobre la tabla de
ciudades y no sobre las tablas que estn debajo de ella en la jerarqua de herencia. Muchas de las
rdenes que ya se han mencionado (SELECT, UPDATE y DELETE) admiten la notacin ONLY.
http://pgsqltutorial.readthedocs.org/en/latest/part_iii/inheritance.html

Consultar esta URL.

http://www.slideshare.net/JulioRo1/postgres-oo

Herencia
La herencia es un concepto de las bases de datos objeto-relacionales. Esto abre nuevas posibilidades
para el diseo de bases de datos.
Creemos dos tablas: Una tabla ciudades y una tabla capitales. Naturalmente, las capitales son ciudades,
por lo que quizs quiera mostrar implcitamente las capitales cuando liste las ciudades. Si es inteligente
, podra pensar un esquema as:
CREATE TABLE capitales (
nombre
text,
poblacion real,
altitud
int,
-- (in ft)
estado
char(2)
);
CREATE TABLE no_capitales (
nombre
text,
poblacion real,
altitud
int
-- (in ft)
);
CREATE VIEW ciudades AS
SELECT nombre, poblacion, altitud FROM capitales
UNION
SELECT nombre, poblacion, altitud FROM no_capitales;

Esto funciona bien ya que la consulta funciona, pero se ve feo a la hora de actualizar algunas filas para
una cosa.
Una mejor solucin es:
CREATE TABLE
name
population
altitude
);

ciudades (
text,
real,
int
-- (in ft)

CREATE TABLE capitales (

state
char(2)
) INHERITS (cities);

En este caso, un registro de capitales hereda todas las columnas (name, population, y altitude) de la
tabla padre, ciudades. El tipo de la columna name es texto, un tipo nativo de PostgreSQL para campos
variables de caracter. Las capitales poseen una columna adicional state, que muestra el estado al que
pertenece la capital. En PostgreSQL, una tbala puede heredar desde cero a ms tablas.

Por ejemplo, la siguiente consulta encuentra los nombre de todas las ciudades, incluido el estado de
algunas capitales, que estan ubicadas a una altitud superior a los 500 pies:
SELECT name, altitude
FROM ciudades
WHERE altitude > 500;

retorna:
name
| altitude
-----------+---------Las Vegas |
2174
Mariposa |
1953
Madison
|
845
(3 rows)

Por otra parte, la siguiente consulta encuentra todas las ciudades que no son capitales de estado y que
estan situadas a una altitud de 500 pies o superior:
SELECT name, altitude
FROM ONLY cities
WHERE altitude > 500;
name
| altitude
-----------+---------Las Vegas |
2174
Mariposa |
1953
(2 rows)

La palabra ONLY indica que la consulta deber correr solo sobre la tabla que le precede, y no sobre las
tablas jerarquicamente dependientes. Muchos de los comandos que discutimos - SELECT, UPDATE, and
DELETE - soportan esta notacin.
http://www.arpug.com.ar/trac/wiki/tutorial-inheritance.html

Herencia
PostgreSQL ofrece como caracterstica particular la herencia entre tablas, que permite
definir una tabla que herede de otra previamente definida.

La tabla persona definida como sigue:

create table persona (
nombre1 varchar (30),
nombre2 varchar (30),
Apaterno varchar (30),
AMaterno varchar (30),
calle varchar (30)
colonia
codigoPostal
NumeroExt
CURP varchar (20)
Tel1
Tel2
Email1
Email2
RFC
sexo
grupoSanguineo
);
A partir de esta definicin, crear la tabla estudiante derivada de la tabla persona:
create table estudiante (
Id_estudiante varchar(8),
carrera varchar(50),
grupo char,
gradoSemestre int
tutor varchar(50)

inherits (persona);
En la tabla estudiante se definen las columnas id_estudiante, carrera, grupo,
gradoSemestre y tutor, pero al solicitar informacin de la estructura de la tabla observar
que tambin incluye las columnas definidas en persona:

demo=# \d estudiante
Table "estudiante"
Column
|Type
| Modifiers
---------------+-----------------------+----------id_estudiante | character varying(8) |

nombre1
direccion
carrera
grupo
gradoSemestre
tutor

|
|
|
|
|
|

character varying(30)
character varying(30)
character varying(50)
character(1)
integer
character varying(50)

|
|
|
|
|
|

En este caso, a la tabla persona la llamamos padre y a la tabla estudiante, hija.

Cada registro de la tabla estudiante contiene 7 valores porque tiene 7 columnas:
demo=# insert into estudiante values (SP003, Juan ,`Treboles 21
,`Ingenieria en Computacion,`A,3);
INSERT 24781 1

La herencia no slo permite que la tabla hija contenga las columnas de la tabla padre,
sino que establece una relacin conceptual es-un.
La consulta del contenido de la tabla estudiante mostrar, por supuesto, un solo registro.
Es decir, no se heredan los datos, nicamente los campos (atributos) del objeto:
demo=# select * from estudiante;

nombre |direccion
|carrera
|grupo | grado
--------+-------------+---------------------------+-------+------Juan
| Treboles 21 | Ingenieria en Computacion | A
| 3
(1 row)

Adems, la consulta de la tabla persona mostrar un nuevo registro:

demo=# select * from persona;
nombre
| direccion
-----------------------+------------Federico Garca Lorca
| Granada 65
Alejandro Magno
| Babilonia
Juan
| Treboles 21
(3 rows)

El ltimo registro mostrado es el que fue insertado en tabla estudiante, sin embargo la herencia define
una relacin conceptual en la que un estudiante es-una persona.
Por lo tanto, al consultar cuntas personas estn registradas en la base de datos, se incluye en el
resultado a todos los estudiantes.
Para consultar slo a las personas que no son estudiantes, podemos utilizar el modificador ONLY:
demo=# select * from only persona;
nombre
| direccion

-----------------------+-----------Alejandro Magno
| Babilonia
Federico Garca Lorca | Granada 65
(2 rows)
No es posible borrar una tabla padre si no se borran primero las tablas hijo.
demo=# drop table persona;
NOTICE: table estudiante depende de table persona
ERROR: no se puede eliminar table persona porque otros objetos
dependen de l
HINT: Use DROP ... CASCADE para eliminar adems los objetos
dependientes.

Como es lgico, al borrar la fila del nuevo estudiante que hemos insertado, se borra de las dos
tablas.

Tanto si lo borramos desde la tabla persona, como si lo borramos desde la tabla estudiante.

http://www.dataprix.com/42-herencia