3.2 Esquema de las bases de datos .

10
Para pasar a tablas todos los datos sin dejar nada y que las tablas tengan sentido por si solas se tiene que seguir unos pasos: 1. Toda entidad se transforma en una tabla. 2. Todo atributo se transforma en una columna dentro de la tabla a la que pertenece. 3. El identificador de la entidad se convierte en la clave primaria de la tabla. 4. Toda relación N:M se convierte en una tabla que tendrá como clave primaria las dos claves primarias de las entidades que se asocian. 3.2 Esquema de las bases de datos.

description

3.2 Esquema de las bases de datos . Para pasar a tablas todos los datos sin dejar nada y que las tablas tengan sentido por si solas se tiene que seguir unos pasos : Toda entidad se transforma en una tabla. - PowerPoint PPT Presentation

Transcript of 3.2 Esquema de las bases de datos .

Page 1: 3.2  Esquema de las bases de datos .

Para pasar a tablas todos los datos sin dejar nada y que las tablas tengan sentido por si solas se tiene que seguir unos pasos:

1. Toda entidad se transforma en una tabla.2. Todo atributo se transforma en una columna dentro de la tabla

a la que pertenece.3. El identificador de la entidad se convierte en la clave primaria

de la tabla.4. Toda relación N:M se convierte en una tabla que tendrá como

clave primaria las dos claves primarias de las entidades que se asocian.

3.2 Esquema de las bases de datos.

Page 2: 3.2  Esquema de las bases de datos .

5. En las relaciones 1:N la clave primaria de la entidad con cardinalidad 1 pasa a la tabla de la entidad cuya cardinalidad es N.

6. En las relaciones N:M existen tres posibilidades: Si la cardinalidad es (0,1) en ambas entidades, se crea tabla. Mientras que si la cardinalidad de una es (0,1) y de la otra es (1,1) se suele pasar la clave primaria de (1,1) a la de (0,1). Si la cardinalidad de ambas es (1,1) se pasa la clave de cualquiera de ellas a la otra.

Page 3: 3.2  Esquema de las bases de datos .
Page 4: 3.2  Esquema de las bases de datos .

CLAVE CANDIDATA Conjunto de atributos que identifican unívocamente cada tupla de la relación. Es

decir columnas cuyos valores no se repiten en ninguna otra tupla de esa tabla. Toda tabla en el modelo relacional debe tener al menos una clave candidata

(puede incluso haber más) CLAVE PRIMARIA Clave candidata que se escoge como identificador de las tuplas. Se elige como

primaria la candidata que identifique mejor a cada tupla en el contexto de la base de datos.

Por ejemplo un campo con el DNI sería clave candidata de una tabla de clientes, si esa tabla tiene un campo de código de cliente, éste sería mejor candidato (y por lo tanto clave principal) porque es mejor identificador para ese contexto.

CLAVE ALTERNATIVA Cualquier clave candidata que no sea primaria.

3.3 Claves.

Page 5: 3.2  Esquema de las bases de datos .

CLAVE EXTERNA, AJENA O SECUNDARIA Son los datos de atributos de una tabla cuyos valores están relacionados con

atributos de otra tabla. Por ejemplo en la tabla equipos tenemos estos datos: Equipo Nº Equipo Real Madrid 1 F.C. Barcelona 2 Athletic Bilbao 3 En la tabla anterior la clave principal es el atributo nº equipo. En otra tabla tenemos: Nº Jugador Jugador Nº Equipo 1 Karanka 3 2 Ronaldinho 2 3 Raúl 1 4 Beckham 1 El atributo Nº Equipo sirve para relacionar el Jugador con el equipo al que pertenece.

Ese campo en la tabla de jugadores es una clave secundaria.

Page 6: 3.2  Esquema de las bases de datos .

En 1978, IBM desarrolla el lenguaje QBE. Que aproximaba la idea relacional a sus ficheros VSAM. En 1979 Oracle se convierte en el primer producto comercial DBMS relacional

(RDBMS). En 1980 aparece Ingres que utilizaba el lenguaje Quel que implementaba el cálculo relacional.

 

3.4 Lenguajes de consulta.

Page 7: 3.2  Esquema de las bases de datos .

Evolución del modelo relacional1970 Codd publica las bases del modelo relacional1971-72 Primeros desarrollos teóricos1973-78 Primeros prototipos1978 Aparece el lenguaje QBE1979 Aparece Oracle1980 Aparece Ingres1981 Aparece SQL1982 Aparece DB21986 ANSI normaliza el SQL (SQL/ANSI)1987 SQL de ISO1990 Versión dos del modelo relacional (RM/V2)1992 SQL 921998 SQL 31992 SQL 92

Page 8: 3.2  Esquema de las bases de datos .

Un lenguaje de consulta es un lenguaje con el que los usuarios solicitan información de la BBDD. Estos lenguajes suelen ser de nivel superior que el de los lenguajes de programación habituales. Clasificación Procedimentales El usuario indica al sistema que lleve a cabo una serie de operaciones en la BBDD para calcular el resultado. No procedimentales El usuario describe la información deseada sin dar un procedimiento concreto para obtener la información.

Page 9: 3.2  Esquema de las bases de datos .

Lenguajes Formales del Modelo RelacionalSe parte de los esquemas de relaciones y se define un lenguaje de manipulación de datos. Dentro de estos lenguajes podemos encontrar Álgebra Relacional (Procedimental) Cálculo Relacional de Tuplas (No procedimental) Cálculo Relacional de Dominios (No procedimental)Estos lenguajes son estrictos y formales y han servido como base para los lenguajes implementados en los SGBD comerciales que veremos posteriormente.

Page 10: 3.2  Esquema de las bases de datos .

Álgebra Relacional Lenguaje de consulta procedimental basado en álgebra de conjuntos.Serie de operaciones que toman una o dos relaciones como entrada y generan una relación como salida, pero siempre sin modificar los datos de la base de datos (es un lenguaje de consulta). Las operaciones son: Selección Proyección Reunión (JOIN o producto cartesiano con condición) División Operaciones habituales de conjuntos: unión, intersección, resta y producto cartesiano.El conjunto completo (conjunto de operaciones que permiten realizar todas las operaciones posibles) en este lenguaje es:{unión, resta, producto cartesiano, selección, proyección