Agosto – Septiembre 2018
Distribución Gratuita Circulación Nacional E D I C I O N C O L E C C I O N A B L E
N
Modelo
Relacional IMS
ATENCION USUARIOS
Subsistema Multimedia IP
TRANSFORMAR UN
NORMALIZACION RELACIONAL
MODELO E/R AL M/R
Evita la redundancia de los datos
Edgar Codd
¿Algebra Relacional?
Tomar operaciones para computar respuestas
SQL Lenguaje de consulta estructurada
Odalys_vasquez25 1
Odalys Vasquez
BASE DE DATOS El nacimiento de las Bases de Datos relacionales Cuando la gente habla de Bases de Datos, regularmente se refieren a Bases de datos electrónicas más estructuradas
tales
como
Rela-
cionales, Objetos, OLAP o espaciales.
Edgar Frank Codd (Ted Codd), fue un científico informático inglés (19 de agosto de 1923 - 18 de abril de 2003), conocido por crear el modelo relacional de bases de datos. En las décadas de los sesenta y los setenta trabajó en sus teorías sobre modelado de datos, publicando su trabajo Un modelo relacional de datos para grandes bancos de datos compartidos (título original: A Relational Model of Data for Large Shared Data Banks), en 1970. Para su descontento, IBM no se apresuró a explotar sus sugerencias hasta que no empezaron
a
ser
puestas
en
práctica
por
rivales
comerciales. Por ejemplo, Larry Ellison diseñó la base de datos Oracle basándose en las ideas de Codd
2
Las 3 Bases de Datos NoSQL más populares para iniciarse en la Nube
3
MODELO RELACIONAL
CONTENIDO
EDITORIAL
05
MODELO DE DATOS RELACIONAL
06
Su historia comenzó en el año 1970 Un objetivo es no influir su manipulación lógica Los elementos son importantes porque nos ayudan a realizar las tablas Contemplaremos tres tipos de restricciones NORMALIZACION DE RELACIONES
10
Para conectar atributos se usan dependencias funcionales ¿Las formas normales son aplicadas a las tablas de una base de datos?
LENGUAJES DE CONSULTAS
12
Existen dos tipos de lenguajes: Procedental (El álgebra relacional) y el no procedental (el cálculo relacional) TRANSFORMAR EL ESQUEMA CONCEPTUAL AL RELACIONAL
17
Existen reglas para poder pasar de modelo conceptual a relacional
REPORTAJE ESPECIAL
18
NOTA DE CIERRE
19
4
MODELO RELACIONAL E D I C I O N
Modelo
C O L E C C I O N A B L E
Relacional IMS
Subsistema Multimedia IP
ATENCION USUARIOS
NORMALIZACION RELACIONAL
TRANSFORMAR UN MODELO E/R AL M/R
Evita la redundancia de los datos
¿Algebra Relacional? Tomar operaciones para computar respuestas
Edgar Codd
SQL Lenguaje de consulta estructurada
Editora Odalys Vasquez Directora Odalys Vasquez Consejo editorial Odalys Vasquez Ixel medina Yraida Quero Coordinadora Editorial Osmeiry Vasquez Redaccion Omar Vasquez Andreina Meléndez Corredor Ismael Medina Colaboradores Yoli Chirinos Jelean Dominguez Inv. Angela.com Fotografía Neosmarly Gutierrez Contacto Comercial Jesusangel@edition.com Contacto Editorial Modelorelacional@alegocomunicaciones.com Modelorelacional@cobeca.com Montaje y diseño Editorial Tendencia Cabimas C.A Fotolito e impresión Editorial Dios es amor C.A Distribución Distribuidora Continental C.A Alianzas para un modelo relacional modelorelacional@basedatos.com DEPOSITO LEGAL No. Pp200692DC4578
EDITORIAL L
a revista Modelo Relacional enseña como el padre(Codd) del modelo de datos relacional propuso a la IBM de presentar a los usuarios datos de forma estructurada, el cual sería llamada relaciones definidas como tuplas; esta idea fue rechazada en un principio; pero esta idea al pasar días fue tomada por la universidad Berkeley en California. Ellos fueron los que creyeron en esta idea que lograron obtener financiamiento para llevar a cabo un sistema Es importante tener en cuenta que el modelo de datos relacional tiene 12 reglas que fueron creadas en 1985 por el científico informático ingles Edgar Frank Codd. El modelo relacional estaba basado en una teoría de conjuntos matemáticos que sirven para múltiples propósitos como: Abstraer la representación de datos de su almacenaje físico y manipularlos.
Modelo relacional no solo esta dirigido para una sola clase de persona, por lo contrario queremos que cada tipo de persona pueda leer e indagar cada proceso de un modelo relacional dentro la informática; esta revista esta seccionada en varios artículos relevantes al modelo relacional. Si la persona lee cuidadosamente esta revista se adentra en un mundo donde podrá aprender a incrementar la consistencia de los datos que tenemos como ejemplo cambiar los datos de un cliente, este cambiara en todos los reportes que se hagan acerca de ese cliente. Nos despedimos y que disfruten esta revista. El equipo editorial.
5
MODELO RELACIONAL
MODELO DE DATOS RELACIONAL
El sistema R de IBM nació de este trabajo, pero fue ignorado por IBM, y poco después Oracle saco su versión comercial de BD basada en la teoría relacional de
Codd, y el Berkely Ingres. El proyecto de investigación Berkeley
Ingres
fue
también
comenzado por este tiempo y consistía en extender el modelo relacional para que trabajara con modelos datos,
más
complejos
de
modelos
de
muchos
objetos y objetos relacionales tienen sus principios en Ingres. Otros Modelos Relacionales de BD empezaron a brotar de estos modelos
pioneros,
Infor-
mix;sybase y el proyecto Ingres dieron nacimiento al Potsgres el
cual consiste en agregar más características orientadas a objetos al modelo relacional, después se transformó en PostgresSQL.
El
sistema
nacimiento a DB2.
R
dio
C
odd propuso que los sistemas de base de datos deberían presentarse a los usuarios con una presentación de los datos organizados en estructuras llamadas relaciones definidas como conjuntos de tuplas (filas) y no como series o secuencias de objetos, con lo que el orden no es importante. Por tanto, detrás de una relación puede haber cualquier estructura de datos compleja que permita una respuesta rápida a una variedad de consultas, Codd hizo entonces énfasis en que el usuario de un sistema relacional solo debía preocuparse por el ¿que consultar? y no el ¿cómo? de las estructuras de almacenamiento (lo que ahora se conoce como modelo físico). Aun hoy se consideran validas sus afirmaciones. Puede parecer extraño, 6
pero las ideas de Codd no fueron “recibidas con los brazos abiertos” en IBM, donde realizaba sus labores de investigación, según afirma Harlwood Kolskin, un físico y antiguo compañero de Codd; fue un enfoque revolucionario, recuerda Kolskin. El nuevo enfoque de Codd, basado en la teoría matemática de conjuntos, no tuvo eco inmediato en la IBM, que prefirió a IMS, un producto al que se la había invertido una fuerte cantidad de esfuerzo y dinero. Un grupo de la universidad de Berkeley en California, liderado por Michael Stonebreaker, creyó en la idea del modelo relacional y obtuvo financiamiento para desarrollar un sistema, el Ingres, cuya primera versión se presentó en 1974 y fue el primer manejador relacional de bases de datos funcional.
MODELO RELACIONAL
MODELO DE DATOS RELACIONAL
El System R con características del multiusuario y un lenguaje de consulta estructurado, el SEQUEL que luego pasaría a llamarse SQL (Structured Query Language). Para entonces Larry Ellison,
un empresario del Valle del Silicón, había tomado ventaja de los escritos de Codd para crear un nuevo producto y una nueva empresa que hasta la fecha se conoce como Oracle.
En 1985 Codd publico sus famosas 12 reglas sobre el modelo relacional de bases de datos, un resumen de sus características fundamentales. Es preciso resaltar que todavía hoy algunas de estas reglas son difíciles de implementar para los fabricantes de manejadores de bases de datos relacionales. Además de ser considerado como el padre del modelo relacional, Codd también incursiono en el modelo multidimensional de análisis de datos conocido como OLAP (On Line Analytical Processing) y en 1993 Codd y algunos de sus colegas publicaron las “12 reglas para OLAP”. 7
MODELO RELACIONAL
MODELO DE DATOS RELACIONAL
Objetivos del modelo de datos relacional
INDEPENDENCIA FISICA: La forma de almacenar los datos, no debe influir en su manipulación lógica. INDEPENDECIA LOGICA: Las aplicaciones que utilizan las bases de datos no deben ser modificadas por que se modifiquen elementos de la bases de datos. FLEXBILIDAD: La base de datos ofrece fácilmente distintas vistas en función de los usuarios y aplicaciones. UNIFORMIDAD: Las estructuras lógicas siempre tienen una única forma conceptual (las tablas). SENCILLEZ.
TABLA
CLAVES
Son estructuras encargadas de alojar la información de la base de datos.
Es el campo cuyo contenido no puede estar duplicado en la misma tabla y permite identificar a cada registro de manera univoca.
CAMPOS Son cada una de las columnas de una tabla, cada campo almacena un dato en concreto.
REGISTROS Cada una de las filas de la tabla que agrupa toda la información de un mismo elemento.
RELACIONES Son los vínculos establecidos entre las diferentes tablas que permiten trabajar con los datos de todas ellas, como si estuvieran en una sola.
CONSULTA Mediante el uso de consulta se puede extraer información concreta aunque la misma provenga de varias tablas.
FORMULARIOS Son ventanas que permiten trabajar de manera cómoda sobre el contenido de varias tareas simultáneamente.
8
INFORMES De la base de datos se adquiere información y se imprime, o a través de un pantallazo.
MODELO ENTIDAD – RELACION Es una herramienta para el modelado de datos de un sistema de información. Estos modelos expresan entidades relevantes para un sistema de información así como su interrelación y
propiedades.
INTEGRIDAD REFERENCIAL Es una propiedad deseable en las bases de datos. Gracias a la integridad referencial se garantiza que una entidad (fila o registro) siempre se relaciona con otras entidades validas, es decir, que existe en la base de datos. Implica que en todo momento dichos datos sean correctos, sin repeticiones.
MODELO RELACIONAL
MODELO DE DATOS RELACIONAL 1. Integridad de clave 1. 2. 3. 4. 5. 6. 7. 8. 9.
El atributo ALUMNO.dni no puede tomar valor nulo. El atributo PROVINCIA.cod_prov no puede tomar valor nulo. El atributo PROVINCIA.nombre no puede tomar valor nulo. El atributo UNIVERSIDAD.cod_univ no puede tomar valor nulo. El atributo FACULTAD.cod_univ no puede tomar valor nulo. El atributo FACULTAD.cod_fac no puede tomar valor nulo. El atributo ALUMNO_FACULTAD.dni no puede tomar valor nulo. El atributo ALUMNO_FACULTAD.cod_univ no puede tomar valor nulo. El atributo ALUMNO_FACULTAD.cod_fac no puede tomar valor nulo.
2. Integridad referencial 1.
2.
3.
4.
El atributo ALUMNO.cod_prov siempre debe tener un valor que se encuentre en PROVINCIA.cod_prov, o bien ser nulo (p.e. si se desconoce la provincia donde vive un alumno). El atributo FACULTAD.cod_univ siempre debe tener un valor que se encuentre en UNIVERSIDAD.cod_univ. No puede ser nulo por la restricción de integridad de clave número 5. El atributo ALUMNO_FACULTAD.dni siempre debe tener un valor que se encuentre en ALUMNO.dni. No puede ser nulo por la restricción de integridad de clave número 7. La agregación de los atributos ALUMNO_FACULTAD.cod_univ y ALUMNO_FACULTAD.cod_fac siempre debe tener un valor que se encuentre en la agregación de los atributos FACULTAD.cod_univ y FACULTAD.cod_fac. No vale cada atributo por separado.
3. Otras restricciones 1. 2. 3. 4. 5. 6.
El atributo ALUMNO.dni solo puede tomar valores numéricos enteros de 8 cifras. El atributo ALUMNO.edad solo puede tomar valores numéricos enteros de 2 cifras, mayores que 15. El atributo PROVINCIA.nombre no puede tomar valores repetidos. El atributo UNIVERSIDAD.tipo solo puede tomar uno de dos valores posibles: 1 (pública) o 2 (privada). El atributo FACULTAD.num_cursos solo puede tomar un valor numérico entero en el intervalo [4,6]. El atributo ALUMNO_FACULTAD.curso_inicio solo puede tomar valores numéricos no menores que 1998.
El modelo relacional de datos contempla tres tipos de restricciones: 1. Integridad de la clave. Ningún atributo de una clave candidata puede tomar valores nulos. Lógicamente, los atributos que forman una clave candidata han de tomar siempre valores distintos para cada posible tupla. 2. Integridad de referencia o referencial. Sea
9
T1.a un atributo de la tabla T1 que forma parte de una clave ajena para la tabla T2. Es decir, que en T2 existe una atributo definida con el mismo dominio, aunque no obligatoriamente con igual nombre, y que es parte de su clave primaria. Entonces, T1.a debe ser siempre igual a algún valor ya contenido en el atributo referenciado en la tabla T2, o bien tomar un valor nulo.
3. Otras restricciones de acuerdo con la semántica concreta del problema. Pueden ser sencillas, como la especificación de valores mínimos o máximos que puede tomar un atributo numérico, lista de valores permitidos de un atributo, o más complejas: condiciones sobre valores de los atributos en función de valores de otros atributos de esa u otras tablas.
MODELO RELACIONAL
NORMALIZACION DE RELACIONES
U
na dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si se conoce el valor de DNI tiene una conexión con Apellido o Nombre.
en el DNI, entonces con el DNI podemos determinar la dirección o su nombre.
De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener estas dependencias funcionales para lograr la eficiencia en las tablas.
Si con el DNI se determina el nombre de una persona, entonces con el DNI más la dirección también se determina el nombre y su dirección.
Propiedades de la dependencia funcional: Existen tres axiomas de Armstrong:
Dependencia funcional argumentativa:
Dependencia funcional transitiva
Dependencia funcional reflexiva: A partir de cualquier atributo o conjunto de atributos siempre puede deducirse el mismo. Si la dirección o el nombre de una persona están incluidos 10
B es funcionalmente dependiente de A
Dependencia funcional transitiva
MODELO RELACIONAL
NORMALIZACION DE RELACIONES
Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de dato está en la forma normal N, es decir que todas sus tablas están en la forma normal N.
Diagrama de inclusión de todas las formas normales.
E
n general, las primeras 3 formas normales son sufícientes para cubrir las necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales(o reglas) fue Edgar F. Codd. Primera Forma Normal (1FN)
Segunda Forma Normal (2FN) Dependencia funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir, que no existen dependencias parciales.
Una tabla está en primera Tercera Forma Normal (3FN) Forma Normal si: La tabla se encuentra en 3FN si es 2FN y si no existe ninguna Todos los atributos son atómicos. Un atributo dependencia funcional transitiva es atómico, si los en los atributos que no son clave. elementos del dominio son simples e indivisibles. La tabla contiene una clave primaria única. La clave primaria no contiene atributos nulos. No debe existir variación en el número de columnas. Los campos no clave deben identificarse por la clave(dependencia funcional) Debe existir una independencia de orden tanto de las filas como de las columnas. 11
MODELO RELACIONAL
LENGUAJES DE CONSULTAS
Existen dos tipos de lenguajes de consultas: de tipo procedencial y los de tipo no procedencial. Los lenguajes no procedenciales se basan en el cálculo relacional y los procedentales se basan en el álgebra relacional. El Cálculo Relacional es un lenguaje de consulta que describe la respuesta deseada sobre una base de datos sin especificar como obtenerla a diferencia del Algebra Relacional que es un tipo procedental, el Cálculo Relacional es de tipo declarativo: pero siempre ambos métodos logran los mismos resultados.
12
MODELO RELACIONAL
LENGUAJES DE CONSULTAS
El cálculo relacional basado en tuplas es un cálculo introducido por Edgar Frank Codd como parte del cálculo relacional, el cual pertenece al modelo relacional para bases de datos. Fue la inspiración para la creación de los lenguajes de consulta QUEL y SQL, de los cuales este último, aunque menos fiel al original, es ahora el lenguaje de consulta más usado. El cálculo relacional basado en dominio, formulado por Michel Lacroix and Alain Pirotte, se aproxima más a la lógica de primer orden, sin embargo ambos son equivalentes en su poder expresivo.
Es un lenguaje de consulta formal que permite expresar las consultas a partir de fórmulas bien formadas, donde cada variable se interpreta como variante sobre el dominio del atri-
buto de una relación. Al igual que el anterior, éste se deduce del cálculo de predicados pero en este caso: 1. Las variables están asociadas a los dominios de los atributos y se denota como relación (atributo1: variable1, atributo2: variable2,...). Ej.: Modelo Carro (modelo: m, marca: c). 2. Los predicados utilizados se construyen igual que para el cálculo relacional de tuplas
13
MODELO RELACIONAL
LENGUAJES DE CONSULTAS
E
s un método que consiste básicamente en crear o construir nuevas relaciones a partir de relaciones existentes.
Existen dos tipos de operadores algebraicos: Operadores básicos o primitivos Operadores no básicos o derivados - Operadores básicos o primitivos: Se clasifican en: A. Proyección (π) B. Selección(σ) C. Unión(U) D. Diferencia(-) E. Producto cartesiano(X)
- Operadores no básicos o derivados: Se clasifican en: A. Intersección (∩) B. Unión natural() C. División(/) 14
MODELO RELACIONAL
PROYECCION Este operador permite extraer columnas de una relación y de esta manera crea un subconjunto de atributos, además elimina las filas duplicadas. SELECCIÓN Este operador permite seleccionar un subconjunto de filas o registros de una relación y de acuerdo a la condición planteada los registros serán seleccionados para formar parte de un nuevo subconjunto. UNION La unión de 2 relaciones R y S es otra relación la cual va a tener los registros de R en S o en ambas, además se eliminan los registros duplicados. En esta relación R y S deben ser compatibles, es decir, deben estar definidas sobre el mismo conjunto de atributos. DIFERENCIA La diferencia de dos relaciones R y S es otra relación la cual va a tener los registros que están en R pero no están en S. En esta relación R y S deben ser compatibles. PRODUCTO CARTESIANO Es una relación que consiste en la concatenación de cada una de las filas de la relación R con cada una de las filas de la relación S. 15
MODELO RELACIONAL
INTERSECCION Es una relación que contiene el conjunto de todas las filas que están tanto en la relación R como en la S. R y S deben ser compatibles.
UNION NATURAL El resultado es una relación con los atributos de ambas relaciones y se obtiene cambiando las filas de ambas relaciones que tengan el mismo valor en los atributos comunes. El join se usa entre los atributos comunes de las entidades o tablas que poseen la clave primaria de una tabla foránea correspondiente de otra entidad.
DIVISION Define una relación sobre el conjunto de atributos C, incluido en la revisión S, que en las filas de R están combinadas con cada una de las filas de S. 16
MODELO RELACIONAL REGLAS PARA TRANSFORMAR EL ESQUEMA CONCEPTUAL (E-R) AL RELACIONAL
2.5.- Atributos multievaluados: Se crea una nueva relación formada con la clave primaria de la entidad y el atributo multievaluado, siendo ambos claves primaria de la nueva relación.
“Cada tipo de entidad se transforma en una relación”
2.6.- Atributos compuestos: Se transforman en los atributos simples (campos) que componen el atributo compuesto, desapareciendo este como tal de la relación.
Un atributo de una entidad se transforma en un atributo (columna) de la relación en la cual se ha transformado la entidad: si el atributo el estaba definido sobre un dominio en el modelo relacional queda también definido sobre el mismo dominio (con la excepción de los atributos multievaluados. 2,1.- Identificador principal (IP): Se transforma en la clave primaria de la relación.
Ejemplo de transformación de una entidad con atributos opcionales, compuestos y multivaluados
2.2.- Identificadores alternativos (IA): Se transforman en claves alternativas en el modelo relacional.
2.3.- Atributos obligatorios: Se transforman en una columna de la relación en la cual se ha transformado la entidad, no admitiendo valores nulos. 2.4.- Atributos opcionales: Se transforman en una columna de la relación en la cual se ha transformado la entidad, admitiendo valores nulos.
17
MODELO RELACIONAL REPORTAJE ESPECIAL
LA INVENCION DE EDGAR COOD TIENE MAYOR IMPACTO QUE LA DE DAVID L. CHILDS. En 1967, Edgar Cood se incorpora al centro de investigación de IBM en San José, California. Mientras Childs publica sus trabajos, Codd trata de inventar un sistema más eficiente de almacenamiento que las bases de datos indexadas secuenciales y las bases de datos jerárquicas. Él trabaja sobre una teoría de la disposición de los datos basados en las “relaciones”. En 1970, sus trabajos llegan a un resultado y tiene una idea genial: Él piensa que, gracias a su almacenamiento de datos organizados en “relaciones”, la teoría de Childs puede tener lugar a una implementación de un lenguaje “universal”, que lo llamó “Universal Data Sublanguage”. Él publica entonces el famoso artículo A relational Model of Data for Large Shared Data Banks (Un Modelo Relacional de datos para Grandes Bancos de Datos Compartidos). A diferencia del artículo de Childs, este artículo tiene un gran impacto.
¿CON QUE OBJETIVO COOD CREO EL MODELO RELACIONAL DE BASE DE DATOS? Edgar Cood un brillante matemático y científico de la computación enfoco sus ideas en el trabajo y desarrollo de informes técnicos para tener una forma de organizar y acceder a los datos. El Modelo Relacional de base de datos haciendo énfasis en que el usuario de un sistema relacional solo debía preocuparse en el ¿Qué consultar? Y no el ¿Cómo? De las estructuras de almacenamiento lo que ahora se conoce como modelo físico. Las actividades de los usuarios en sus terminales y la mayoría de los programas de aplicación no debería verse afectados cuando se cambia la representación interna de los datos o incluso cuando se cambian algunos aspectos de la representación externa. Se necesitara cambiar la representación de los datos a menudo como resultados de los cambios en el tráfico de las consultas, actualizaciones e informes y como consecuencia del crecimiento natural en los tipos de información almacenada. La aparición del modelo relacional representa un verdadero hito en el desarrollo de las bases de datos, ya que ha marcado tres etapas diferentes, conocidas como SGBD´s:
Pre-relaciones: Los SGDB se basan en modelos Codasyl (en red) y jerárquico y ficheros planos (flat files). Relacionales: Los sistemas relacionales ganan madurez en el mercado y los productos basados en este modelo van desplazando poco a poco a los sistemas basados en punteros de la etapa pre-relacional. Post-relacionales: Aparecen manifiestos de otros modelos de datos, en especial los orientados a objetos. Se distinguen manifiestos puristas OO que dan lugar a SGBD´s-OO puros como O2, Gemstone, etc.: y en paralelo corrientes evolutivas del modelo relacional que relajan hipótesis básicas del modelo relacional de Cood (relajación de la primera forma normal) para ofrecer estructuras de datos más complejas. Se propone una evolución desde el modelo relacional a SGDB´s-OO relacionales, Ej.: SQL3.
Hoy en día el modelo de bases de datos más usado es el modelo relacional. Han pasado 30 años desde que paso de ser el sistema R al Oracle, pero aun así en la actualidad este es el modelo dominante. En el año 1978, durante una reunión técnica de alto nivel el modelo relacional llamo la atención de IBM. Más tarde IBM anuncio SQLDS, su primer producto relacional comercial en 1981, seguido de DB2 en 1983. Este modelo tiene una muy importante evolución:
Años 50: Almacenamientos en cintas magnéticas. Años 60: Almacenamientos en discos. Bases de datos jerárquicas y de red. Años 70: Bases de datos relacionales. Años 80: Bases de datos orientadas a objetos. Años 90: Lenguajes de consultas SQL. Bases de datos en internet.
18
MODELO RELACIONAL NOTA DE CIERRE
L
a revista Modelo Relacional contiene mucha información importante para nuestras vidas porque como lo desglosamos este fue creado por Cood para que los sistemas de Base de Datos ya no fueran presentadas como series o secuencias sino que pasaran a ser estructuras llamadas relaciones definidas como conjuntos de tuplas (Filas). Un Modelo de Datos Relacionales tienes sus elementos para hacer de este una buena estructura de Base de Datos Electrónicas, quien inspiro a que surgieran nuevas Base de Datos, ya que, rivales comerciales se basaron en las ideas de Cood, consecuencia que surgió por el motivo de que la IBM se tardó en lanzar este proyecto en el tiempo que se esperaba. Entre las Bases de Datos inspiradas por las de Cood tenemos las Bases de Datos Oracle, que fue creada por Larry Ellison , Base de Datos El Ingres esta fue creada por Michael Stonebreaker. Existen elementos importantes para crear el Modelo de Datos Relacionales entre los cuales tenemos que para comenzar hay que hacer tablas para tener la información de la Base de Datos, luego se realiza el campo donde este refleja cada una de las columnas de una tabla y así sucesivamente seguiríamos empleando los elementos de un Modelo de Datos Relacionales. Gracias. El equipo Editorial. 19
MODELO RELACIONAL
¿Qué es una base de datos relacional? Es una base de datos que cumple con el modelo relacional
¿Por qué es importante? Establece conexiones entre los datos y trabaja con ellos conjuntamente. Ayuda a Modelar problemas reales Administra datos dinámicamente
20