SlideShare uma empresa Scribd logo
1 de 12
Modelo Relacional
• El objetivo del modelo relacional es crear un
"esquema", el cual consiste en un conjunto de
"tablas" que representan "relaciones", relaciones
entre los datos.
• Fue propuesto originariamente por E.F. Codd en
1970. Gracias a su coherencia y facilidad de
uso, el modelo se ha convertido en los años 80
en el más usado para la producción de DBMS.
Elaborado por Gisell García Albelais
• La estructura fundamental del modelo relacional
es precisamente esa, "relación", es decir una
tabla bidimensional constituida por líneas (tuplas)
y columnas (atributos).
• Las relaciones representan las entidades que se
consideran interesantes en la base de datos.
• Cada instancia de la entidad encontrará sitio en
una tupla de la relación, mientras que los
atributos de la relación representarán las
propiedades de la entidad.
Elaborado por Gisell García Albelais
• Por ejemplo, si en la base de datos se tienen que
representar personas, se podrá definir una
relación llamada "Personas", cuyos atributos
describen las características de las personas
(tabla siguiente). Cada tupla de la relación
"Personas" representará una persona concreta.
Elaborado por Gisell García Albelais
Persona
Nombre Apellido Nacimiento Sexo Estado Civil
Juan Loza 15/06/1971 H Soltero
Isabel Gálvez 23/12/1969 M Casada
Micaela Ruiz 02/10/1985 M Soltera
Elaborado por Gisell García Albelais
• En realidad, siendo rigurosos, una relación es
sólo la definición de la estructura de la tabla, es
decir su nombre y la lista de los atributos que la
componen.
• Cuando se puebla con las tuplas, se habla de
"instancia de relación". Por eso, la tabla anterior
representa una instancia de la relación persona.
• Una representación de la definición de esa
relación podría ser la siguiente:
Personas (nombre, apellido, fecha_nacimiento,
sexo, estado_civil)
Elaborado por Gisell García Albelais
• A continuación, se indicarán ambas (relación e
instancia de relación) con el término "relación”.
• Las tuplas en una relación son un conjunto en el
sentido matemático del término, es decir una
colección no ordenada de elementos diferentes.
• Para distinguir una tupla de otra, se recurre al
concepto de "llave primaria", o sea a un conjunto de
atributos que permiten identificar unívocamente una
tupla en una relación. Naturalmente, en una relación
puede haber más combinaciones de atributos que
permitan identificar unívocamente una tupla ("llaves
candidatas"), pero entre éstas se elegirá una sola
para utilizar como llave primaria.
Elaborado por Gisell García Albelais
• Los atributos de la llave primaria no pueden
asumir el valor nulo (que significa un valor no
determinado), en tanto que ya no permitirían
identificar una tupla concreta en una relación.
Esta propiedad de las relaciones y de sus llaves
primarias está bajo el nombre de integridad de
las entidades.
Elaborado por Gisell García Albelais
• Cada atributo de una relación se caracteriza por un nombre y por un
dominio. El dominio indica qué valores pueden ser asumidos por una
columna de la relación. A menudo un dominio se define a través de la
declaración de un tipo para el atributo (por ejemplo diciendo que es
una cadena de diez caracteres), pero también es posible definir
dominios más complejos y precisos.
• Por ejemplo, para el atributo "sexo" de nuestra relación "Personas"
podemos definir un dominio por el cual los únicos valores válidos son
'M' y 'F'; o bien por el atributo "fecha_nacimiento" podremos definir
un dominio por el que se consideren válidas sólo las fechas de
nacimiento después del uno de enero de 1960, si en nuestra base de
datos no está previsto que haya personas con fecha de nacimiento
anterior a esa.
• El motor de datos se ocupará de controlar que en los atributos de
las relaciones se incluyan sólo los valores permitidos por sus
dominios. Característica fundamental de los dominios de una base
de datos relacional es que sean "atómicos", es decir que los valores
contenidos en las columnas no se puedan separar en valores de
dominios más simples.
Elaborado por Gisell García Albelais
• Más formalmente se dice que no es posible tener
atributos multivalor. Por ejemplo, si una
característica de las personas en nuestra base
de datos fuese la de tener uno o más hijos, no
sería posible escribir la relación Personas de la
siguiente manera:
• Personas
(nombre, apellido, fecha_nacimiento, sexo, estad
o_civil, hijos)
Elaborado por Gisell García Albelais
• En efecto, el atributo hijos es un atributo no-
atómico, bien porque una persona puede tener
más de un hijo o porque cada hijo tendrá
diferentes características que lo describen. Para
representar estas entidades en una base de
datos relacional hay que definir dos relaciones:
• Personas
(*número_persona, nombre, apellido, fecha_naci
miento, sexo, estado_civil)
Hijos(*número_persona,*nombre_apellido, edad,
sexo)
Elaborado por Gisell García Albelais
• En las relaciones precedentes, los asteriscos (*) indican
los atributos que componen sus llaves primarias. Nótese
la introducción en la relación Personas del atributo
número_persona, a través del cual se asigna a cada
persona un identificativo numérico unívoco que se usa
como llave primaria.
• Estas relaciones contienen sólo atributos atómicos. Si
una persona tiene más de un hijo, éstos se representarán
en tuplas diferentes de la relación Hijos.
• Las diferentes características de los hijos las representan
los atributos de la relación Hijos. La unión entre las dos
relaciones está constituida por los atributos
número_persona que aparecen en ambas relaciones y
que permiten que se asigne cada tupla de la relación
hijos a una tupla concreta de la relación Personas.
Elaborado por Gisell García Albelais

Mais conteúdo relacionado

Mais procurados

Casos prácticos de uml
Casos prácticos de umlCasos prácticos de uml
Casos prácticos de umlsemillachile
 
Entity Relationship Model
Entity Relationship ModelEntity Relationship Model
Entity Relationship ModelSlideshare
 
UML. un analisis comparativo para la diagramación de software
UML.  un analisis comparativo para la diagramación de softwareUML.  un analisis comparativo para la diagramación de software
UML. un analisis comparativo para la diagramación de softwareYaskelly Yedra
 
Clase 04a requerimientos introduccion
Clase 04a requerimientos introduccionClase 04a requerimientos introduccion
Clase 04a requerimientos introduccionDemián Gutierrez
 
Programación 3: árboles binarios y ordenados
Programación 3: árboles binarios y ordenadosProgramación 3: árboles binarios y ordenados
Programación 3: árboles binarios y ordenadosAngel Vázquez Patiño
 
Elicitacion de requerimientos
Elicitacion de requerimientosElicitacion de requerimientos
Elicitacion de requerimientosTensor
 
Modelo entidad relacion
Modelo entidad relacionModelo entidad relacion
Modelo entidad relacionMaria Garcia
 
Metodología orientada a objetos
Metodología orientada a objetosMetodología orientada a objetos
Metodología orientada a objetosalcrrsc
 
Diccionario de datos
Diccionario de datosDiccionario de datos
Diccionario de datosmiranda271999
 
Programación Orientada a Objetos - Unidad 2: clases y objetos
Programación Orientada a Objetos - Unidad 2: clases y objetosProgramación Orientada a Objetos - Unidad 2: clases y objetos
Programación Orientada a Objetos - Unidad 2: clases y objetosJosé Antonio Sandoval Acosta
 

Mais procurados (20)

Casos prácticos de uml
Casos prácticos de umlCasos prácticos de uml
Casos prácticos de uml
 
Entity Relationship Model
Entity Relationship ModelEntity Relationship Model
Entity Relationship Model
 
UML. un analisis comparativo para la diagramación de software
UML.  un analisis comparativo para la diagramación de softwareUML.  un analisis comparativo para la diagramación de software
UML. un analisis comparativo para la diagramación de software
 
Componentes de un SGBD
Componentes de un SGBDComponentes de un SGBD
Componentes de un SGBD
 
Introduccion a Uml
Introduccion a Uml Introduccion a Uml
Introduccion a Uml
 
Clase 04a requerimientos introduccion
Clase 04a requerimientos introduccionClase 04a requerimientos introduccion
Clase 04a requerimientos introduccion
 
Programación 3: árboles binarios y ordenados
Programación 3: árboles binarios y ordenadosProgramación 3: árboles binarios y ordenados
Programación 3: árboles binarios y ordenados
 
Modelo Conceptual UML
Modelo Conceptual UMLModelo Conceptual UML
Modelo Conceptual UML
 
Elicitacion de requerimientos
Elicitacion de requerimientosElicitacion de requerimientos
Elicitacion de requerimientos
 
Modelo entidad relacion
Modelo entidad relacionModelo entidad relacion
Modelo entidad relacion
 
Modelo ER
Modelo ERModelo ER
Modelo ER
 
Metodología orientada a objetos
Metodología orientada a objetosMetodología orientada a objetos
Metodología orientada a objetos
 
Modelo de entidad relación extendido
Modelo de entidad relación extendidoModelo de entidad relación extendido
Modelo de entidad relación extendido
 
Diagramas uml
Diagramas umlDiagramas uml
Diagramas uml
 
NORMALIZACIÓN
NORMALIZACIÓN  NORMALIZACIÓN
NORMALIZACIÓN
 
Modelo relacional
Modelo relacionalModelo relacional
Modelo relacional
 
Flujo datos
Flujo datosFlujo datos
Flujo datos
 
Diccionario de datos
Diccionario de datosDiccionario de datos
Diccionario de datos
 
Modelos de datos
Modelos de datosModelos de datos
Modelos de datos
 
Programación Orientada a Objetos - Unidad 2: clases y objetos
Programación Orientada a Objetos - Unidad 2: clases y objetosProgramación Orientada a Objetos - Unidad 2: clases y objetos
Programación Orientada a Objetos - Unidad 2: clases y objetos
 

Destaque (7)

Reglas de transformacion
Reglas de transformacionReglas de transformacion
Reglas de transformacion
 
Algebra Relacional
Algebra RelacionalAlgebra Relacional
Algebra Relacional
 
Modelo entidad relacion-reduccion_a_tablas
Modelo entidad relacion-reduccion_a_tablasModelo entidad relacion-reduccion_a_tablas
Modelo entidad relacion-reduccion_a_tablas
 
Proceso de normalizacion
Proceso de normalizacionProceso de normalizacion
Proceso de normalizacion
 
Celabración de la milagrosa 2012
Celabración de la milagrosa 2012Celabración de la milagrosa 2012
Celabración de la milagrosa 2012
 
Fbd e1 fase_3_modelos_de_datos
Fbd e1 fase_3_modelos_de_datosFbd e1 fase_3_modelos_de_datos
Fbd e1 fase_3_modelos_de_datos
 
Modelo entidad relacion
Modelo entidad relacionModelo entidad relacion
Modelo entidad relacion
 

Semelhante a Modelo relacional

Modelamiento de-entidad relacion
Modelamiento de-entidad relacionModelamiento de-entidad relacion
Modelamiento de-entidad relacionAnthonyLeonRuiz
 
Actividad 2.1 modelo e r
Actividad 2.1 modelo e rActividad 2.1 modelo e r
Actividad 2.1 modelo e rjesh85
 
Modelo entidad de relación mendoza
Modelo entidad de relación mendozaModelo entidad de relación mendoza
Modelo entidad de relación mendozaRosii Pezo
 
Modelo entidad de relación mendoza
Modelo entidad de relación mendozaModelo entidad de relación mendoza
Modelo entidad de relación mendozaRosii Pezo
 
Diapositivas de informatica david
Diapositivas de informatica davidDiapositivas de informatica david
Diapositivas de informatica davidDavid Rodriguez
 
Base de datos segunda parte
Base de datos segunda parteBase de datos segunda parte
Base de datos segunda parteeduardo2797
 
Modelo entidad relacion ok
Modelo entidad relacion okModelo entidad relacion ok
Modelo entidad relacion okBB
 
3a5 victor uquillas-tarea 1
3a5 victor uquillas-tarea 13a5 victor uquillas-tarea 1
3a5 victor uquillas-tarea 1jusphe
 
Modelo conceptual
Modelo conceptual Modelo conceptual
Modelo conceptual Claü Vides
 
Modelo Entidad Relacion
Modelo Entidad Relacion Modelo Entidad Relacion
Modelo Entidad Relacion Johaeli92
 
Base datos 2 camila florez maria florez
Base datos 2 camila florez maria florezBase datos 2 camila florez maria florez
Base datos 2 camila florez maria florezCamila Florez
 
Modelo entidad relación presentacion
Modelo entidad relación presentacionModelo entidad relación presentacion
Modelo entidad relación presentacionCarlos Ortega
 
Universidad catolica santiago de guayaquil
Universidad catolica santiago de guayaquilUniversidad catolica santiago de guayaquil
Universidad catolica santiago de guayaquilluigi87238
 

Semelhante a Modelo relacional (20)

Modelamiento de-entidad relacion
Modelamiento de-entidad relacionModelamiento de-entidad relacion
Modelamiento de-entidad relacion
 
entidad relacion
entidad relacionentidad relacion
entidad relacion
 
Actividad 2.1 modelo e r
Actividad 2.1 modelo e rActividad 2.1 modelo e r
Actividad 2.1 modelo e r
 
Base de datos
Base de datosBase de datos
Base de datos
 
Modelo entidad de relación mendoza
Modelo entidad de relación mendozaModelo entidad de relación mendoza
Modelo entidad de relación mendoza
 
Modelo entidad de relación mendoza
Modelo entidad de relación mendozaModelo entidad de relación mendoza
Modelo entidad de relación mendoza
 
Dbd1.2
Dbd1.2Dbd1.2
Dbd1.2
 
Diapositivas de informatica david
Diapositivas de informatica davidDiapositivas de informatica david
Diapositivas de informatica david
 
Base de datos segunda parte
Base de datos segunda parteBase de datos segunda parte
Base de datos segunda parte
 
Modelo entidad relacion ok
Modelo entidad relacion okModelo entidad relacion ok
Modelo entidad relacion ok
 
Trabajo de sistemas andrey
Trabajo de sistemas andreyTrabajo de sistemas andrey
Trabajo de sistemas andrey
 
3a5 victor uquillas-tarea 1
3a5 victor uquillas-tarea 13a5 victor uquillas-tarea 1
3a5 victor uquillas-tarea 1
 
Modelo entidad relación
Modelo entidad relaciónModelo entidad relación
Modelo entidad relación
 
Modelo entidad relacion
Modelo entidad relacionModelo entidad relacion
Modelo entidad relacion
 
Modelo conceptual
Modelo conceptual Modelo conceptual
Modelo conceptual
 
Modelo Entidad Relacion
Modelo Entidad Relacion Modelo Entidad Relacion
Modelo Entidad Relacion
 
Base datos 2 camila florez maria florez
Base datos 2 camila florez maria florezBase datos 2 camila florez maria florez
Base datos 2 camila florez maria florez
 
Modelo entidad relación presentacion
Modelo entidad relación presentacionModelo entidad relación presentacion
Modelo entidad relación presentacion
 
Universidad catolica santiago de guayaquil
Universidad catolica santiago de guayaquilUniversidad catolica santiago de guayaquil
Universidad catolica santiago de guayaquil
 
Deber 1
Deber 1 Deber 1
Deber 1
 

Mais de Universidad Estatal de Sonora

Norma de educacion_profesional_continua_para_2011_modificaciones
Norma de educacion_profesional_continua_para_2011_modificacionesNorma de educacion_profesional_continua_para_2011_modificaciones
Norma de educacion_profesional_continua_para_2011_modificacionesUniversidad Estatal de Sonora
 

Mais de Universidad Estatal de Sonora (20)

Prese
PresePrese
Prese
 
El contador
El contadorEl contador
El contador
 
Responsabilidad fiscal y penal del Contador
Responsabilidad fiscal y penal del ContadorResponsabilidad fiscal y penal del Contador
Responsabilidad fiscal y penal del Contador
 
Presentación catálogo de cuentas y estructura
Presentación catálogo de cuentas y estructuraPresentación catálogo de cuentas y estructura
Presentación catálogo de cuentas y estructura
 
Mapa mental conceptual cuadro
Mapa mental conceptual cuadroMapa mental conceptual cuadro
Mapa mental conceptual cuadro
 
Necesidades satisface lc
Necesidades satisface lcNecesidades satisface lc
Necesidades satisface lc
 
Particularidades de la profesion
Particularidades de la profesionParticularidades de la profesion
Particularidades de la profesion
 
Particularidades de la profesion
Particularidades de la profesionParticularidades de la profesion
Particularidades de la profesion
 
Norma de educacion_profesional_continua_para_2011_modificaciones
Norma de educacion_profesional_continua_para_2011_modificacionesNorma de educacion_profesional_continua_para_2011_modificaciones
Norma de educacion_profesional_continua_para_2011_modificaciones
 
Profesional de la contaduria
Profesional de la contaduriaProfesional de la contaduria
Profesional de la contaduria
 
Reglas de transformación
Reglas de transformaciónReglas de transformación
Reglas de transformación
 
Material didactico fbd
Material didactico fbdMaterial didactico fbd
Material didactico fbd
 
Fundamentos de base_de_datos_e1
Fundamentos de base_de_datos_e1Fundamentos de base_de_datos_e1
Fundamentos de base_de_datos_e1
 
Experiencia integradora elemento 3
Experiencia integradora elemento 3Experiencia integradora elemento 3
Experiencia integradora elemento 3
 
Fuentes confiables para recabar datos
Fuentes confiables para recabar  datosFuentes confiables para recabar  datos
Fuentes confiables para recabar datos
 
Power point act 22 pau
Power point act 22 pauPower point act 22 pau
Power point act 22 pau
 
Image6
Image6Image6
Image6
 
Tractor rastreando
Tractor rastreandoTractor rastreando
Tractor rastreando
 
U2inecte10
U2inecte10U2inecte10
U2inecte10
 
Internacionalización
InternacionalizaciónInternacionalización
Internacionalización
 

Modelo relacional

  • 1.
  • 2. Modelo Relacional • El objetivo del modelo relacional es crear un "esquema", el cual consiste en un conjunto de "tablas" que representan "relaciones", relaciones entre los datos. • Fue propuesto originariamente por E.F. Codd en 1970. Gracias a su coherencia y facilidad de uso, el modelo se ha convertido en los años 80 en el más usado para la producción de DBMS. Elaborado por Gisell García Albelais
  • 3. • La estructura fundamental del modelo relacional es precisamente esa, "relación", es decir una tabla bidimensional constituida por líneas (tuplas) y columnas (atributos). • Las relaciones representan las entidades que se consideran interesantes en la base de datos. • Cada instancia de la entidad encontrará sitio en una tupla de la relación, mientras que los atributos de la relación representarán las propiedades de la entidad. Elaborado por Gisell García Albelais
  • 4. • Por ejemplo, si en la base de datos se tienen que representar personas, se podrá definir una relación llamada "Personas", cuyos atributos describen las características de las personas (tabla siguiente). Cada tupla de la relación "Personas" representará una persona concreta. Elaborado por Gisell García Albelais
  • 5. Persona Nombre Apellido Nacimiento Sexo Estado Civil Juan Loza 15/06/1971 H Soltero Isabel Gálvez 23/12/1969 M Casada Micaela Ruiz 02/10/1985 M Soltera Elaborado por Gisell García Albelais
  • 6. • En realidad, siendo rigurosos, una relación es sólo la definición de la estructura de la tabla, es decir su nombre y la lista de los atributos que la componen. • Cuando se puebla con las tuplas, se habla de "instancia de relación". Por eso, la tabla anterior representa una instancia de la relación persona. • Una representación de la definición de esa relación podría ser la siguiente: Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil) Elaborado por Gisell García Albelais
  • 7. • A continuación, se indicarán ambas (relación e instancia de relación) con el término "relación”. • Las tuplas en una relación son un conjunto en el sentido matemático del término, es decir una colección no ordenada de elementos diferentes. • Para distinguir una tupla de otra, se recurre al concepto de "llave primaria", o sea a un conjunto de atributos que permiten identificar unívocamente una tupla en una relación. Naturalmente, en una relación puede haber más combinaciones de atributos que permitan identificar unívocamente una tupla ("llaves candidatas"), pero entre éstas se elegirá una sola para utilizar como llave primaria. Elaborado por Gisell García Albelais
  • 8. • Los atributos de la llave primaria no pueden asumir el valor nulo (que significa un valor no determinado), en tanto que ya no permitirían identificar una tupla concreta en una relación. Esta propiedad de las relaciones y de sus llaves primarias está bajo el nombre de integridad de las entidades. Elaborado por Gisell García Albelais
  • 9. • Cada atributo de una relación se caracteriza por un nombre y por un dominio. El dominio indica qué valores pueden ser asumidos por una columna de la relación. A menudo un dominio se define a través de la declaración de un tipo para el atributo (por ejemplo diciendo que es una cadena de diez caracteres), pero también es posible definir dominios más complejos y precisos. • Por ejemplo, para el atributo "sexo" de nuestra relación "Personas" podemos definir un dominio por el cual los únicos valores válidos son 'M' y 'F'; o bien por el atributo "fecha_nacimiento" podremos definir un dominio por el que se consideren válidas sólo las fechas de nacimiento después del uno de enero de 1960, si en nuestra base de datos no está previsto que haya personas con fecha de nacimiento anterior a esa. • El motor de datos se ocupará de controlar que en los atributos de las relaciones se incluyan sólo los valores permitidos por sus dominios. Característica fundamental de los dominios de una base de datos relacional es que sean "atómicos", es decir que los valores contenidos en las columnas no se puedan separar en valores de dominios más simples. Elaborado por Gisell García Albelais
  • 10. • Más formalmente se dice que no es posible tener atributos multivalor. Por ejemplo, si una característica de las personas en nuestra base de datos fuese la de tener uno o más hijos, no sería posible escribir la relación Personas de la siguiente manera: • Personas (nombre, apellido, fecha_nacimiento, sexo, estad o_civil, hijos) Elaborado por Gisell García Albelais
  • 11. • En efecto, el atributo hijos es un atributo no- atómico, bien porque una persona puede tener más de un hijo o porque cada hijo tendrá diferentes características que lo describen. Para representar estas entidades en una base de datos relacional hay que definir dos relaciones: • Personas (*número_persona, nombre, apellido, fecha_naci miento, sexo, estado_civil) Hijos(*número_persona,*nombre_apellido, edad, sexo) Elaborado por Gisell García Albelais
  • 12. • En las relaciones precedentes, los asteriscos (*) indican los atributos que componen sus llaves primarias. Nótese la introducción en la relación Personas del atributo número_persona, a través del cual se asigna a cada persona un identificativo numérico unívoco que se usa como llave primaria. • Estas relaciones contienen sólo atributos atómicos. Si una persona tiene más de un hijo, éstos se representarán en tuplas diferentes de la relación Hijos. • Las diferentes características de los hijos las representan los atributos de la relación Hijos. La unión entre las dos relaciones está constituida por los atributos número_persona que aparecen en ambas relaciones y que permiten que se asigne cada tupla de la relación hijos a una tupla concreta de la relación Personas. Elaborado por Gisell García Albelais