Hola compañeros hasta ahora he trabajado bien usando sqlite pero he instalado postgresql y funciona con pgadmin pero no veo donde se hace una relación gráfica  también instale mysql lo configuré tiene para crear bases de datos tablas y todo pero no veo donde o mejor dicho como hago las relaciones de las tablas para hacer consultas y llenado de datos gracias

===================
CONTROL SYSTEMS-((CELIS))

Hola
Quisiera que me precisaras si tu pregunta se refiere exclusivamente a cuestiones de obtener una query con datos procedentes de tablas diversas o bien te refieres a integración referencial, foreign keys y cosillas de esats.

Es que son dos casos completamente distintos.

Supongo que tu vas por el primer caso que es lo mas genera.

Un saludo
 

Bueno me encantaría que respondieras los dos casos que dices por query y forkey la verdad nunca he usado estas bases de datos disculpa mi ignorancia te lo agradecería de antemano te voy a presentar como quisiera que la relación se hiciera.

ejemplos:
Poseo una tabla que se llama asesores y otra llamada asistencia como podría relacionar (Un profesor tiene muchas Asistencias) eso es todo sea por código manual  o por relación gráfica que al pasar el primer asesor se registre su hora de entrada y salida tantas veces y se vea que solo el posee un código y se vea cuantas veces cada uno de ellos entro y salio durante la semana o día mas nada gracias esa pregunta tuya también me puso a pensar bastantico amigo.

===================
CONTROL SYSTEMS-((CELIS))

En mysql puedes hacer varias cosas

Crear una consulta que saque datos de varias tablas
Imagina una tabla de clientes y otra de facturas. En la tabla de clientes tienes todos los datos del cliente. En la de facturas tienes los datos de la factura y el dni del cliente al que pertenece.

select f.*, c.nombre, c.direccion,c.codigopostal
   from facturas f inner join clientes c
   on f.dni=c.dni
where c.dni="xxx"

Esto te saca todos los registros en los que coincida el dni de facturas y el de clientes y de ellos lo que cumpla la claúsula where.

En otro caso en vez de poner inner join puedes poner
select f.*, c.nombre, c.direccion,c.codigopostal
   from facturas f left join clientes c
   on f.dni=c.dni
where c.dni="xxx"
Esto te saca TODO lo de el lado de la izquierda (facturas) y solo lo de la derecha cuyo dni coincida. Un cliente que no tiene facturas no sale. De ese conjunto de datos lo que cumpla la claúslla where.

En otro caso en vez de poner left join puedes poner
select f.*, c.nombre, c.direccion,c.codigopostal
   from facturas f right join clientes c
   on f.dni=c.dni
where c.dni="xxx"
Esto te saca todos lo de la derecha (clientes) y las facturas que les correspondan. De todo ese conjunto lo que cumpla la clausula where.

subconsultas
También puedes hacer subconsultas.
Select * from facturas where dni in select dni from clientes where nombre="xxx"
Esto hace la consulta select dni from clientes where nombre= y obtiene un dni (o varios). Según eso hace la consulta select * from facturas where dni= todos los obtenidos anteriormente.

Las subconsultas también pueden ir en la claúsula from
select avg(totalimportes) from
   select sum(importes) as totalimportes from facturas group by dni

vistas
Si te encuentras que con mucha frecuencia acabas escribiendo la misma sql puedes crear una vista que ya tiene eso
create view BASEDEDATOS.NOMBREVISTA
as aquí una sentencia select

A partir de ese momento puedes usar ese nombre como si fuera el nombre de una tabla en la que estarán los datos de las tablas que correspondan a la select que pusiste.
create view facturascliente as
   select f.*, c.nombre on f.dni=c.dni

A partir de ese momento es como si tu base de datos tuviera una tabla mas llamada facturasclientes que tiene datos de ambas tablas. La mayor diferencia es que en esa vista no puedes hacer triggers (pero si en las tablas subyacentes.

Estas vistas se crean CREATE VIEW, modifican ALTER VIEW, borran DROP VIEW y consultan SHOW VIEWS como cualquier otra cosa.

Vistas en mysql

procedimientos almacenados
Aún puedes hacer mas cosas y mas complejas creando procedimientos almacenados que usan variables, hacen cuentas y devuelven resultados que pueden ser una operación aritmética o un recordset.
Viene muy bien explicado aquí
procedimientos almacenados en mysql

Lo de las foreign keys y las constraints mejor lo dejo por no liarlo mas y seguramente no lo necesitas.

Lo que SQL te permite es relacionar las tablas con la cláusula JOIN

Por ejemplo:
Suponiendo que tu tabla de asesores sea así:

id            numérico, clave primaria y única
nombre    alfanumérico

y que contenga estos dos registros

1    Pepe Pérez Peluquero
2    Juan Nadie Gris


y la tabla asistencia sea así

id                 numérico clave primaria y única
asesor_id     numerico (corresponde al id del asesor)
fecha           campo de fecha y hora
duración      tiempo que utilizó.

y que contenga los siguientes registros

1   1    20-10-2010      20 minutos
2   1    10-10-2010      30 minutos
3   2    01-10-2010      10 minutos
4   2    02-05-2009      15 minutos

Si pides algo así:

SELECT  asesores.nombre, asistencias.fecha, asistencias.hora FROM asesores INNER JOIN asistencias ON asesores.id=asistencias.asesor_id WHERE year(asistencias.fecha) > 2009 ORDER BY asesores.nombre,asistencias.fecha

Obtendrás esto
 
Juan Nadie Gris                01-10-2010    10 minutos
Pepe Perez Peluquero       10-10-2010    30 minutos
Pepe Perez Peluquero       20-10-2010    20 minutos

SELECT va seguido de los campos (precedidos por el nombre de la tabla y un punto) que quieres ver.
FROM va seguido de las tablas que quieres usar
INNER JOIN establece el tipo de relación entre ellas (En este caso INNER hace que sólo salgan las filas cuyo campo de relación exista en las dos tablas)
WHERE va seguido de la condición de filtro de las filas resultantes (no sale la asistencia número 5 porque el año de su fecha no es mayor que 2009)
ORDER BY va seguido por los campos en los que quieres ordenar el resultado.

En esencia así se establece una relación entre dos tablas a la hora de consultar (por supuesto puede llegar a ser mucho más complejo si relacionamos más tablas y añadimos más condiciones).
El problema es que podemos borrar un asesor de la tabla, o que después de haber metido 100 asistencias de un asesor tengamos que cambiarle el id por cualquier motivo ¿qué pasa entonces con los registros de la tabla asistencias correspondientes a ese asesor?
Evidentemente podemos escribir en nuestro programa una serie de rutinas y funciones que se encarguen de borrar los registros relacionados, pero eso puede ser trabajoso, poco seguro y, además, no siempre borraremos o modificaremos registros desde el programa, muchas veces lo haremos con un gestor de base de datos, como phpmyadmin para bases mysql o el que lleva el propio gambas.
¿Qué hacer entonces? Pues establecer lo que se llama "Integridad Referencial" en la propia base de datos (que no todas lo soportan, ojo)
Es decir, le decimos a la base de datos algo así como:

ALTER TABLE asistencias ADD FOREIGN KEY ( asesor_id ) REFERENCES asesores (id) ON DELETE CASCADE ON UPDATE CASCADE ;

Con esto le decimos que el campo asesor_id hace referencia (es clave externa) del campo id de la tabla asesores y que cuando se borre el registro o se actualice dicho campo se produzca un borrado o actualización "en cascada" en la tabla asistencias (es decir que se borren o actualicen todos los registros con ese asesor_id), sin que nosotros tengamos que preocuparnos más por el asunto.

¿Cómo puedes implementar todo esto en Mysql? (nunca he trabajado con postgre) pues eligiendo un tipo InnoDB para las tablas (por defecto son MyISAM, que no soporta la integridad referencial) y estableciendo las relaciones vía escribir las órdenes o utilizando un gestor de base de datos (recomiendo phpmyadmin que en sus últimas versiones permite hasta la creación gráfica de relaciones).

Básicamente este es el camino a seguir. Espero que te sirva de algo la información.

Suerte

===================
No podemos regresar

Je, je, Soplo, se nos han cruzado las respuestas... casi escribimos un manual entre los dos....

===================
No podemos regresar

pero tu lo has explicado mejor je je je

me sumo
como hago

[list]integridad referencial
eliminacion en cascada
actualizacion es cascada[/list]

Pues para seguir con el ejemplo de clientes y facturas pongamos lo siguiente:

Tabla clientes de tipo innodb y primary key codigocliente

tabla facturas de tipo innodb, primary key codigofactura.

Para establecer una relación entre ellas de uno a muchos enter clientes (uno) y facturas (muchos) lo que hacemos es:

a facturas le creamos una FOREIGN KEY codigocliente REFERENCES clientes.codigocliente
Con esto hemos creado una clave en la tabla clientes por el campo codigocliente
Esta clave foranea puede llamarse de cualquier forma. Yo la he puesto también codigocliente para que se vea a que se refiere, pero lo importante es el references que es quien identifica a que campo de que tabla se refiere.

Indexamos facturas por codigocliente

Desde ese momento ya están relacionadas con una relación uno a muchos lo cual significa que no es posible tener una factura sin cliente. Si intentamos introducir una factura con un cliente que no exista dará error porque la relación establece que puede haber clientes sin factura, pero no facturas sin cliente.

Tampoco podremos borrar un cliente que tenga facturas porque esas facturas quedarán sin cliente y eso no es posible A MENOS QUE se realice una operación de borrado EN CASCADA.

Si queremos que se borre en cascada entonces hay que especificarlo al crear la clave foránea tras el references añadiendo ON DELETE CASCADE.
FOREIGN KEY codigocliente REFERENCES clientes.codigocliente ON DELETE CASCADE

En este caso el borrar un cliente hará que se borren en la tabla de facturas todas sus facturas.

Hay que pensarlo TRES VECES antes de utilizar claúsulas de estas en el diseño de una base de datos pero bueno ...

Como veis es muy fácil

estuve practicando en phpadmin con la Tabla clientes y.... y es un poco lioso  

como que me faltan pasos o  todavia no entiendo la mecanica

estuve buscando en google y la informcion es bien rudimentaria