FORO 3
UNIDAD III: PARTE A:
DISEÑO DE BASES DE
DATOS, MODELOS
RELACIONALES Y
NORMALIZACIÓN
Por: Erika Plaza.
Universidad del Quindío. Facultad de Ciencias
Humanas y Bellas Artes. Ciencia de la
Información y la Documentación,
Bibliotecología y Archivística.
Bases de Datos.
FORO 3
1. ¿Cuál es el modelo de entidad relación que propone Richard Baker en
la técnica de modelado de datos? Explicar o dar ejemplos.
El modelo entidad relación identifica asuntos de importancia para una
organización a los que se llamará entidades, las propiedades de esos asuntos
llamadas atributos y como se relacionan entre sí (relación). Los objetivos de este
modelo son:
 Facilitar un modelo específico de acuerdo a las necesidades de
información de la organización.
 Desempeñarse como un marco de trabajo para el desarrollo de sistemas
nuevos o mejorados.
 Proporcionar un modelo independiente de cualquier almacenamiento de
datos y método de acceso, facilitando la toma de decisiones objetivas en
relación con las técnicas de implementación y la coexistencia con sistemas
más antiguos.
Para desarrollar el modelo entidad relación es necesario tener en cuenta los
siguientes aspectos:
Dato: recurso clave. El dato hace parte de la evolución de la organización; es
una ventaja estratégica para una entidad el control de estos recursos de
información.
Compromiso de la dirección: Es esencial para el desarrollo del modelo contar
con la participación y compromiso de la dirección para confirmar los requisitos de
información que requiere.
Convenciones: Es imprescindible incluir convenciones específicas y bien
estructuradas, estándares y directrices, incluyendo los conceptos de
normalización de datos.
Definición mínima: Es importante definir cualquier información o concepto de
una sola forma y luego realizar las asociaciones para los objetos relacionados.
De esta forma se debe definir solo una vez la cosa llamada “pedido de compra” y
posteriormente relacionarlo con el departamento, los productos, las funciones de
autorización, etc.
Independencia de datos: Se deben definir los requisitos de información de
manera independiente a cualquier método de almacenamiento y de acceso, lo
que permitirá una visión creativa y objetiva de la empresa y del diseño
Subsiguiente.
Tomado de:
https://books.google.com.co/books?id=hbOTo05ddxAC&pg=PA11&hl=es&source=gbs_toc_r&cad=3#v=onepage&
q&f=false
Elementos del modelo entidad relación:
 Entidad: objetos relevantes y de interés para una organización. Ejemplo:
Cliente, empleado, pedido, sucursal, factura, etc.
 Relación: Asociación entre dos entidades
 Atributo: Característica importante para una organización.
Las entidades son representadas por cajas de bordes redondeados, no es
importante su tamaño. Cada entidad solo aparece una vez en un modelo y debe
tener un único nombre, que debe ser escrito en mayúsculas y en singular. En
caso de existir un sinónimo para la entidad se puede escribir entre paréntesis o
separado por una barra oblicua.
Las entidades pueden aparecer varias veces dentro del modelo o tener varias
peticiones.
Se pueden presentar dos tipos de entidades:
Entidades débiles: No pueden existir sin la existencia de otras entidades, por
ejemplo, los Detalles de una Factura,
Entidades fuertes: Tienen existencia propia.
Ejemplos de entidades:
– Personas: Alumno, Pasajero, Profesor, Cliente
– Instituciones: Banco, Empresa, Universidad
– Unidades organizacionales: Departamento, Sucursal, Planta, Línea
– Clasificaciones, agrupaciones y jerarquías: Tipo, Clase, Marca,
Grupo, Género
– Documentos: Factura, Pedido, Orden, Cheque
Objetos (físicos o abstractos): Material, Producto, Asignatura, Habilidad.
Las relaciones por su parte establecen una relación bidireccional, significativa y
nombrable, entre dos entidades que no necesariamente deben ser distintas, lo
que se denomina “relación recursiva”.
De esta forma establecen una acción o relación entre las entidades.
Cada dirección de una relación presenta:
Nombre (leyenda)
Opcionalidad: Línea punteada (puede) o continua (debe).
Grado o cardinalidad: un punto (.), que significa uno o el símbolo ( )
que significa muchos. (Moreno, 2015)
Convenciones para la representación:
 Una línea que une las dos entidades relacionadas
 Los nombres de las relaciones en el extremo de cada entidad y en
minúscula
Opcionalidad:
 Obligatoria: Línea continua
 Opcional: Línea discontinua
Cardinalidad o grado
 “Pata de gallina” (Crow’s foot*): Muchos
 Punto (fin de la línea continua o discontinua): Uno.
Es importante evitar leyendas como “relacionado con” o “asociado con”, porque
no aportan información sobre la relación.
No colocar leyendas con verbos en infinitivo (“tener”, “estar”, “poseer”, etc.)  La
lectura de acuerdo con la notación presentada quedaría mal. (Moreno, 2015)
Atributos
Son las características, propiedades que describen a una entidad, identifican,
califican, cuantifican, clasifican o expresan el estado de la entidad.
Los nombres deben ser claros, completos y preferiblemente sin incluir el nombre
de la entidad (Moreno, 2015)
El nombre de los atributos se escribe en minúscula dentro de la caja de la entidad
Se recomienda descomponerlos hasta su mínima expresión semántica.
Aunque es posible tenerlos, se evitarán atributos generados a partir de otros
(problemas de redundancia y consistencia).
Ejemplo: En una entidad ESTUDIANTE con un atributo fecha de nacimiento NO
es necesario tener un atributo edad, si se tienen FACTURAS y sus DETALLES
de productos vendidos NO es necesario tener un atributo para el total de
productos vendidos en la factura.
Atributos Identificadores
Identificador (único) de una entidad:
Conjunto de atributos y/o relaciones que identifican de manera única una entidad.
Ejemplos:
Entidad con un solo identificador: ALUMNO con atributos cédula, nombre y
año nacimiento.
Entidad con varios identificadores candidatos: ELEMENTO QUÍMICO con
número, símbolo, nombre, temp_ebullición.
Entidad con un identificador compuesto por dos atributos*: VEHÍCULO
donde la placa se representa con dos atributos así: letras, dígitos, color, modelo.
Entidad con un identificador compuesto por un atributo y una relación:
CUENTA1con número cuenta (atributo) y cod_sucursal (relación), saldo.
Entidad con un identificador compuesto por un atributo y dos relaciones:
Ej.: PEDIDO2 con la fecha (atributo), cod_producto (relación) y el cod_proveedor
(relación), nro_unidades
Convenciones:
 Se les antepone el símbolo #
 Se coloca una línea paralela a la entidad cerca del punto terminal de la
relación.
 Si hay varios identificadores candidatos, se selecciona uno y se dejan los
demás como secundarios o alternativos*.
 Se pueden definir identificadores artificiales o surrogados para evitar un
identificador compuesto por muchos atributos
1
Dos sucursales pueden tener números de cuenta iguales, pero una misma sucursal no puede tener dos
números de cuenta iguales.
2
Es decir, aquí a un mismo proveedor se le puede pedir el mismo.
2. ¿Amplié el concepto sobre que es un modelo relacional?
El modelo está basado en el concepto matemático de la relación, se fundamenta en
la teoría de “normalización de las relaciones”, que permite eliminar el
comportamiento anormal de las relaciones, luego de actualizaciones, así como el
“control de la redundancia de datos” (Gutierrez, 2011).
Este modelo considera la base de datos como una colección de relaciones. De
manera simple, una relación representa una tabla que no es más que un conjunto
de filas, cada fila es un conjunto de campos y cada campo representa un valor que
interpretado describe el mundo real. Cada fila también se puede denominar tupla o
registro y a cada columna también se le puede llamar campo o atributo.
Atributo: columna en una relación identificada por un nombre.
Tupla / registro: fila en una tabla o relación que contiene un conjunto de valores
acordes al esquema de la relación (sus columnas y dominios).
Esquema de una relación (o tabla): nombre de la relación seguido de la lista de
sus atributos con sus dominios.
Dominio: Conjunto de valores, que puede tomar un área. Por ejemplo:
Colores = {´rojo´, ´verde´, ´azul´}
Marcas = {´fiat´, ´toyota´, ´ford´, ´Honda´}
Esquema
Un esquema contiene la definición de una estructura (generalmente relaciones o
tablas de una base de datos), es decir, determina la identidad de la relación y qué
tipo de información podrá ser almacenada dentro de ella; en otras palabras, el
esquema contiene los metadatos de la relación. Todo esquema constará de:
 Nombre de la relación (su identificador).
 Nombre de los atributos (o campos) de la relación y sus dominios; el dominio de
un atributo o campo define los valores permitidos para el mismo.
Relación: Subconjunto del producto cartesiano de una lista de dominios.
Producto cartesiano: es el cruce de las variables de un domino con las de otro
dominio. Por ejemplo:
Colores = {´rojo´, ´verde´, ´azul´}
Marcas = {´Fiat´, ´Toyota´, ´Ford´}
Se cruzan todas las variables de Marca con las todas las variables de color
Luego se puede tomar un Subconjunto del producto cartesiano de los dominios:
Marca Color
Fiat Rojo
Fiat Verde
Fiat Azul
Toyota Rojo
Toyota Verde
Toyota Azul
Ford Rojo
Ford Verde
Ford Azul
R1={(‘Fiat´, ´verde´), (´Toyota´, ´azul´), (´Ford´, ´rojo´)}
R2= {(´rojo´, ´honda´)}, o bien R3= {}
R1 Marca Color
Fiat Verde
Toyota Azul
Ford Rojo
Instancias
Se puede definir como el contenido de una tabla en un momento dado, pero también
es válido referirnos a una instancia cuando trabajamos o mostramos únicamente un
subconjunto de la información contenida en una relación o tabla, como por ejemplo:
 Ciertos caracteres y números (una sola columna de una sola fila).
 Algunas o todas las filas con todas o algunas columnas
 Cada fila es una tupla. El número de filas es llamado cardinalidad.
 El número de columnas es llamado aridad o grado.
Marca Color
Fiat Rojo
Fiat Verde
Fiat Azul
Toyota Rojo
Toyota Verde
Toyota Azul
Ford Rojo
Ford Verde
Ford Azul
Relación
3. ¿Quién diseño la base de datos Oracle?
Los ingenieros de Sillicon Valley, Larry Ellison, Bob Miner y Ed Oates fundan en
1977 una empresa de consultoría llamada Software Development Laboratories
(SDL) y tiempo después obtienen un contrato con la CIA para diseñar un sistema
especial de bases de datos con código clave "Oracle".
Ellison y Miner habían leído un artículo en la revista IBM Journal of Research and
Development donde se describía una versión preliminar del lenguaje SQL,
basado en el artículo de E. F. Codd donde propone el modelo relacional: "A
Relational Model of Data for Large Shared Data Banks".
En 1978 y buscando la coherencia con sus objetivos empresariales, SDL cambia
de nombre a Relational Software Incorporated (RSI). La compañía busca tener un
producto que fuese compatible con el SQL de IBM, y además enfocarse en un
mercado de las minicomputadoras, abarcando así un segmento que en ese
momento a IBM no le interesaba.
En 1982 RSI cambia su nombre a Oracle Systems Corporation, y poco después
se acorta a su definitivo Oracle Corporation, el siguiente año empieza a
comercializar Oracle V3, agregando el manejo de transacciones a través de las
instrucciones COMMIT y ROLLBACK. De hecho, el producto es recodificado en
C lo que permite expandir las plataformas de ejecución para incluir los entornos
Unix, cuando hasta aquí era solo sobre Digital VAX/VMS.
De esta manera Oracle se convierte en la Primera Base de Datos Diseñada para
Grid Computing, como un sistema de gestión de base de datos relacional
fabricado por Oracle Corporation.
Oracle es básicamente un herramienta cliente/servidor para la gestión de base de
datos la gran potencia que tiene y su elevado precio hace que solo se vea en
empresas muy grandes y multinacionales, por norma general.
Oracle Corporation: es una de las mayores compañías de software del mundo.
Sus productos van desde bases de datos (Oracle) hasta sistemas de gestión.
Cuenta además, con herramientas propias de desarrollo para realizar potentes
aplicaciones, como Oracle Designer.
Características de Oracle Desarrollado sobre Oracle Database: Oracle Content
Database ha sido diseñada para que las organizaciones puedan controlar y
gestionar grandes volúmenes de contenidos no estructurados en un único
repositorio con el objetivo de reducir los costes y los riesgos asociados a la
pérdida de información.
4. ¿Quién definió las tres primeras formas normales?
Edgar F. Codd originalmente definió las tres primeras formas normales (1NF, 2NF,
y 3NF). Estas formas normales se han resumido como requiriendo que todos los
atributos no-clave sean dependientes en "la clave, la clave completa, y nada excepto
la clave".
En la teoría de bases de datos relacionales, las formas normales (NF) proporcionan
los criterios para determinar el grado de vulnerabilidad de una tabla a
inconsistencias y anomalías lógicas. Cuanta más alta sea la forma normal aplicable
a una tabla, menos vulnerable será a inconsistencias y anomalías. Cada tabla tiene
una "forma normal más alta" (HNF): por definición, una tabla siempre satisface los
requisitos de su HNF y de todas las formas normales más bajas que su HNF;
también por definición, una tabla no puede satisfacer los requisitos de ninguna forma
normal más arriba que su HNF. Las formas normales son aplicables a tablas
individuales; decir que una base de datos entera está en la forma normal n es decir
que todas sus tablas están en la forma normal n
5. ¿Cuáles son las 12 reglas de Edgar Frank Codd del modelo relacional
de base de datos? -Explicarla.
Son un sistema de reglas (numeradas del 0 al 12) propuestas por Edgar F. Codd,
del modelo relacional para las bases de datos, diseñado para definir qué requiere
un sistema de administración de base de datos.
Codd se percató de que existían bases de datos en el mercado las cuales decían
ser relacionales, pero lo único que hacían era guardar la información en las tablas,
sin estar estas tablas literalmente normalizadas; entonces éste publicó 12 reglas
que un verdadero sistema relacional debería tener aunque en la práctica algunas
de ellas son difíciles de realizar. Un sistema podrá considerarse "más relacional"
cuanto más 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 información, toda la información en la base de datos es
representada unidireccionalmente, por valores en posiciones de las columnas
dentro de filas de tablas. Toda la información en una base de datos relacional
se representa explícitamente en el nivel Lógico exactamente de una manera:
con valores en tablas.
 Regla 2: la regla del acceso garantizado, todos los datos deben ser accesibles
sin ambigüedad. Esta regla es esencialmente una nueva exposición del requisito
fundamental para las llaves primarias. Dice que cada valor escalar individual en
la base de datos debe ser lógicamente direccionable especificando el nombre
de la tabla, la columna que lo contiene y la llave primaria.
 Regla 3: Tratamiento sistemático de valores nulos, el sistema de gestión de
base de datos debe permitir que haya campos nulos. Debe tener una
representación de la "información que falta y de la información inaplicable" que
es sistemática, distinto de todos los valores regulares.
 Regla 4: catálogo dinámico en línea basado en el modelo relacional, el sistema
debe soportar un catálogo en línea, el catálogo relacional debe ser accesible a
los usuarios autorizados. Es decir, los usuarios autorizados deben poder tener
acceso a la estructura de la base de datos (catálogo).
 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 definición de datos, operaciones de
manipulación de datos (actualización así como la recuperación),
seguridad e integridad y operaciones de administración de
transacciones.
 Regla 6: regla de actualización, todas las vistas que son teóricamente
actualizables deben ser actualizables por el sistema.
 Regla 7: alto nivel de inserción, actualización y borrado, permitiendo el sistema
realizar manipulación de datos de alto nivel, es decir, sobre conjuntos de tuplas.
Esto significa que los datos no solo se pueden recuperar de una base de datos
relacional de filas múltiples y/o de tablas múltiples, sino también pueden
realizarse inserciones, actualización y borrados sobre varias tuplas y/o tablas al
mismo tiempo (no sólo sobre registros individuales).
 Regla 8: independencia física de los datos, los programas de aplicación y
actividades del terminal permanecen inalterados a nivel lógico cuando quiera
que se realicen cambios en las representaciones de almacenamiento o métodos
de acceso.
 Regla 9: independencia lógica de los datos, los cambios al nivel lógico (tablas,
columnas, filas, etc.) no deben requerir un cambio a una solicitud basada en la
estructura. La independencia de datos lógica es más difícil de lograr que la
independencia física de datos.
 Regla 10: independencia de la integridad, las limitaciones de la integridad se
deben especificar por separado de los programas de la aplicación 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 distribución, la distribución 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 versión 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 subversión, 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 limitación de integridad. Esto es debido a que existen
sistemas anteriormente no relacionales que añadieron una interfaz relacional,
pero con la interfaz nativa existe la posibilidad de trabajar no relacionalmente.
BIBLIOGRAFIA
Barker, Richard. El modelo entidad-relación. CASE*METHODTM. Universidad
Pontifica de Salamanca. Madrid, España. Publicado 1990. [En línea] [Citado 23
de octubre de 2015]. Disponible en internet:
https://books.google.com.co/books?id=hbOTo05ddxAC&pg=PA11&hl=es&sourc
e=gbs_toc_r&cad=3#v=onepage&q&f=false
García. Emiliano. Forma normal 123. ACADEMIA.EDU. [en línea] [Citado 23 de
octubre de 2015]. Disponible en internet:
http://www.academia.edu/8400539/Forma_normal_1_2_3
ORACLE. ¿Qué es Oracle?. [En línea] [Citado 23 de octubre de 2015]. Disponible
en internet: https://iessanvicente.com/colaboraciones/oracle.pdf
WIKIPEDIA. Modelo relacional. Modificado 22 de octubre de 2015. [En línea] [Citado
23 de octubre de 2015]. Disponible en internet:
https://es.wikipedia.org/wiki/Modelo_relacional
WIKIPEDIA. 12 Reglas de Codd. Modificada 19 de octubre de 2015. [En línea]
[Citado 23 de octubre de 2015]. Disponible en internet:
https://es.wikipedia.org/wiki/12_reglas_de_Codd

Foro 3

  • 1.
    FORO 3 UNIDAD III:PARTE A: DISEÑO DE BASES DE DATOS, MODELOS RELACIONALES Y NORMALIZACIÓN Por: Erika Plaza. Universidad del Quindío. Facultad de Ciencias Humanas y Bellas Artes. Ciencia de la Información y la Documentación, Bibliotecología y Archivística. Bases de Datos.
  • 2.
    FORO 3 1. ¿Cuáles el modelo de entidad relación que propone Richard Baker en la técnica de modelado de datos? Explicar o dar ejemplos. El modelo entidad relación identifica asuntos de importancia para una organización a los que se llamará entidades, las propiedades de esos asuntos llamadas atributos y como se relacionan entre sí (relación). Los objetivos de este modelo son:  Facilitar un modelo específico de acuerdo a las necesidades de información de la organización.  Desempeñarse como un marco de trabajo para el desarrollo de sistemas nuevos o mejorados.  Proporcionar un modelo independiente de cualquier almacenamiento de datos y método de acceso, facilitando la toma de decisiones objetivas en relación con las técnicas de implementación y la coexistencia con sistemas más antiguos. Para desarrollar el modelo entidad relación es necesario tener en cuenta los siguientes aspectos: Dato: recurso clave. El dato hace parte de la evolución de la organización; es una ventaja estratégica para una entidad el control de estos recursos de información. Compromiso de la dirección: Es esencial para el desarrollo del modelo contar con la participación y compromiso de la dirección para confirmar los requisitos de información que requiere. Convenciones: Es imprescindible incluir convenciones específicas y bien estructuradas, estándares y directrices, incluyendo los conceptos de normalización de datos. Definición mínima: Es importante definir cualquier información o concepto de una sola forma y luego realizar las asociaciones para los objetos relacionados. De esta forma se debe definir solo una vez la cosa llamada “pedido de compra” y posteriormente relacionarlo con el departamento, los productos, las funciones de autorización, etc. Independencia de datos: Se deben definir los requisitos de información de manera independiente a cualquier método de almacenamiento y de acceso, lo que permitirá una visión creativa y objetiva de la empresa y del diseño Subsiguiente.
  • 3.
    Tomado de: https://books.google.com.co/books?id=hbOTo05ddxAC&pg=PA11&hl=es&source=gbs_toc_r&cad=3#v=onepage& q&f=false Elementos delmodelo entidad relación:  Entidad: objetos relevantes y de interés para una organización. Ejemplo: Cliente, empleado, pedido, sucursal, factura, etc.  Relación: Asociación entre dos entidades  Atributo: Característica importante para una organización. Las entidades son representadas por cajas de bordes redondeados, no es importante su tamaño. Cada entidad solo aparece una vez en un modelo y debe tener un único nombre, que debe ser escrito en mayúsculas y en singular. En caso de existir un sinónimo para la entidad se puede escribir entre paréntesis o separado por una barra oblicua. Las entidades pueden aparecer varias veces dentro del modelo o tener varias peticiones. Se pueden presentar dos tipos de entidades: Entidades débiles: No pueden existir sin la existencia de otras entidades, por ejemplo, los Detalles de una Factura, Entidades fuertes: Tienen existencia propia.
  • 4.
    Ejemplos de entidades: –Personas: Alumno, Pasajero, Profesor, Cliente – Instituciones: Banco, Empresa, Universidad – Unidades organizacionales: Departamento, Sucursal, Planta, Línea – Clasificaciones, agrupaciones y jerarquías: Tipo, Clase, Marca, Grupo, Género – Documentos: Factura, Pedido, Orden, Cheque Objetos (físicos o abstractos): Material, Producto, Asignatura, Habilidad. Las relaciones por su parte establecen una relación bidireccional, significativa y nombrable, entre dos entidades que no necesariamente deben ser distintas, lo que se denomina “relación recursiva”. De esta forma establecen una acción o relación entre las entidades. Cada dirección de una relación presenta: Nombre (leyenda) Opcionalidad: Línea punteada (puede) o continua (debe). Grado o cardinalidad: un punto (.), que significa uno o el símbolo ( ) que significa muchos. (Moreno, 2015)
  • 6.
    Convenciones para larepresentación:  Una línea que une las dos entidades relacionadas  Los nombres de las relaciones en el extremo de cada entidad y en minúscula Opcionalidad:  Obligatoria: Línea continua  Opcional: Línea discontinua Cardinalidad o grado  “Pata de gallina” (Crow’s foot*): Muchos  Punto (fin de la línea continua o discontinua): Uno. Es importante evitar leyendas como “relacionado con” o “asociado con”, porque no aportan información sobre la relación. No colocar leyendas con verbos en infinitivo (“tener”, “estar”, “poseer”, etc.)  La lectura de acuerdo con la notación presentada quedaría mal. (Moreno, 2015)
  • 9.
    Atributos Son las características,propiedades que describen a una entidad, identifican, califican, cuantifican, clasifican o expresan el estado de la entidad. Los nombres deben ser claros, completos y preferiblemente sin incluir el nombre de la entidad (Moreno, 2015) El nombre de los atributos se escribe en minúscula dentro de la caja de la entidad Se recomienda descomponerlos hasta su mínima expresión semántica. Aunque es posible tenerlos, se evitarán atributos generados a partir de otros (problemas de redundancia y consistencia). Ejemplo: En una entidad ESTUDIANTE con un atributo fecha de nacimiento NO es necesario tener un atributo edad, si se tienen FACTURAS y sus DETALLES de productos vendidos NO es necesario tener un atributo para el total de productos vendidos en la factura.
  • 11.
    Atributos Identificadores Identificador (único)de una entidad: Conjunto de atributos y/o relaciones que identifican de manera única una entidad. Ejemplos: Entidad con un solo identificador: ALUMNO con atributos cédula, nombre y año nacimiento. Entidad con varios identificadores candidatos: ELEMENTO QUÍMICO con número, símbolo, nombre, temp_ebullición. Entidad con un identificador compuesto por dos atributos*: VEHÍCULO donde la placa se representa con dos atributos así: letras, dígitos, color, modelo. Entidad con un identificador compuesto por un atributo y una relación: CUENTA1con número cuenta (atributo) y cod_sucursal (relación), saldo. Entidad con un identificador compuesto por un atributo y dos relaciones: Ej.: PEDIDO2 con la fecha (atributo), cod_producto (relación) y el cod_proveedor (relación), nro_unidades Convenciones:  Se les antepone el símbolo #  Se coloca una línea paralela a la entidad cerca del punto terminal de la relación.  Si hay varios identificadores candidatos, se selecciona uno y se dejan los demás como secundarios o alternativos*.  Se pueden definir identificadores artificiales o surrogados para evitar un identificador compuesto por muchos atributos 1 Dos sucursales pueden tener números de cuenta iguales, pero una misma sucursal no puede tener dos números de cuenta iguales. 2 Es decir, aquí a un mismo proveedor se le puede pedir el mismo.
  • 13.
    2. ¿Amplié elconcepto sobre que es un modelo relacional? El modelo está basado en el concepto matemático de la relación, se fundamenta en la teoría de “normalización de las relaciones”, que permite eliminar el comportamiento anormal de las relaciones, luego de actualizaciones, así como el “control de la redundancia de datos” (Gutierrez, 2011). Este modelo considera la base de datos como una colección de relaciones. De manera simple, una relación representa una tabla que no es más que un conjunto de filas, cada fila es un conjunto de campos y cada campo representa un valor que interpretado describe el mundo real. Cada fila también se puede denominar tupla o registro y a cada columna también se le puede llamar campo o atributo. Atributo: columna en una relación identificada por un nombre. Tupla / registro: fila en una tabla o relación que contiene un conjunto de valores acordes al esquema de la relación (sus columnas y dominios). Esquema de una relación (o tabla): nombre de la relación seguido de la lista de sus atributos con sus dominios. Dominio: Conjunto de valores, que puede tomar un área. Por ejemplo:
  • 14.
    Colores = {´rojo´,´verde´, ´azul´} Marcas = {´fiat´, ´toyota´, ´ford´, ´Honda´} Esquema Un esquema contiene la definición de una estructura (generalmente relaciones o tablas de una base de datos), es decir, determina la identidad de la relación y qué tipo de información podrá ser almacenada dentro de ella; en otras palabras, el esquema contiene los metadatos de la relación. Todo esquema constará de:  Nombre de la relación (su identificador).  Nombre de los atributos (o campos) de la relación y sus dominios; el dominio de un atributo o campo define los valores permitidos para el mismo. Relación: Subconjunto del producto cartesiano de una lista de dominios. Producto cartesiano: es el cruce de las variables de un domino con las de otro dominio. Por ejemplo: Colores = {´rojo´, ´verde´, ´azul´} Marcas = {´Fiat´, ´Toyota´, ´Ford´} Se cruzan todas las variables de Marca con las todas las variables de color Luego se puede tomar un Subconjunto del producto cartesiano de los dominios: Marca Color Fiat Rojo Fiat Verde Fiat Azul Toyota Rojo Toyota Verde Toyota Azul Ford Rojo Ford Verde Ford Azul
  • 15.
    R1={(‘Fiat´, ´verde´), (´Toyota´,´azul´), (´Ford´, ´rojo´)} R2= {(´rojo´, ´honda´)}, o bien R3= {} R1 Marca Color Fiat Verde Toyota Azul Ford Rojo Instancias Se puede definir como el contenido de una tabla en un momento dado, pero también es válido referirnos a una instancia cuando trabajamos o mostramos únicamente un subconjunto de la información contenida en una relación o tabla, como por ejemplo:  Ciertos caracteres y números (una sola columna de una sola fila).  Algunas o todas las filas con todas o algunas columnas  Cada fila es una tupla. El número de filas es llamado cardinalidad.  El número de columnas es llamado aridad o grado. Marca Color Fiat Rojo Fiat Verde Fiat Azul Toyota Rojo Toyota Verde Toyota Azul Ford Rojo Ford Verde Ford Azul Relación
  • 16.
    3. ¿Quién diseñola base de datos Oracle? Los ingenieros de Sillicon Valley, Larry Ellison, Bob Miner y Ed Oates fundan en 1977 una empresa de consultoría llamada Software Development Laboratories (SDL) y tiempo después obtienen un contrato con la CIA para diseñar un sistema especial de bases de datos con código clave "Oracle". Ellison y Miner habían leído un artículo en la revista IBM Journal of Research and Development donde se describía una versión preliminar del lenguaje SQL, basado en el artículo de E. F. Codd donde propone el modelo relacional: "A Relational Model of Data for Large Shared Data Banks". En 1978 y buscando la coherencia con sus objetivos empresariales, SDL cambia de nombre a Relational Software Incorporated (RSI). La compañía busca tener un producto que fuese compatible con el SQL de IBM, y además enfocarse en un mercado de las minicomputadoras, abarcando así un segmento que en ese momento a IBM no le interesaba. En 1982 RSI cambia su nombre a Oracle Systems Corporation, y poco después se acorta a su definitivo Oracle Corporation, el siguiente año empieza a comercializar Oracle V3, agregando el manejo de transacciones a través de las instrucciones COMMIT y ROLLBACK. De hecho, el producto es recodificado en C lo que permite expandir las plataformas de ejecución para incluir los entornos Unix, cuando hasta aquí era solo sobre Digital VAX/VMS. De esta manera Oracle se convierte en la Primera Base de Datos Diseñada para Grid Computing, como un sistema de gestión de base de datos relacional fabricado por Oracle Corporation. Oracle es básicamente un herramienta cliente/servidor para la gestión de base de datos la gran potencia que tiene y su elevado precio hace que solo se vea en empresas muy grandes y multinacionales, por norma general. Oracle Corporation: es una de las mayores compañías de software del mundo. Sus productos van desde bases de datos (Oracle) hasta sistemas de gestión. Cuenta además, con herramientas propias de desarrollo para realizar potentes aplicaciones, como Oracle Designer. Características de Oracle Desarrollado sobre Oracle Database: Oracle Content Database ha sido diseñada para que las organizaciones puedan controlar y gestionar grandes volúmenes de contenidos no estructurados en un único repositorio con el objetivo de reducir los costes y los riesgos asociados a la pérdida de información.
  • 17.
    4. ¿Quién definiólas tres primeras formas normales? Edgar F. Codd originalmente definió las tres primeras formas normales (1NF, 2NF, y 3NF). Estas formas normales se han resumido como requiriendo que todos los atributos no-clave sean dependientes en "la clave, la clave completa, y nada excepto la clave". En la teoría de bases de datos relacionales, las formas normales (NF) proporcionan los criterios para determinar el grado de vulnerabilidad de una tabla a inconsistencias y anomalías lógicas. Cuanta más alta sea la forma normal aplicable a una tabla, menos vulnerable será a inconsistencias y anomalías. Cada tabla tiene una "forma normal más alta" (HNF): por definición, una tabla siempre satisface los requisitos de su HNF y de todas las formas normales más bajas que su HNF; también por definición, una tabla no puede satisfacer los requisitos de ninguna forma normal más arriba que su HNF. Las formas normales son aplicables a tablas individuales; decir que una base de datos entera está en la forma normal n es decir que todas sus tablas están en la forma normal n 5. ¿Cuáles son las 12 reglas de Edgar Frank Codd del modelo relacional de base de datos? -Explicarla. Son un sistema de reglas (numeradas del 0 al 12) propuestas por Edgar F. Codd, del modelo relacional para las bases de datos, diseñado para definir qué requiere un sistema de administración de base de datos. Codd se percató de que existían bases de datos en el mercado las cuales decían ser relacionales, pero lo único que hacían era guardar la información en las tablas, sin estar estas tablas literalmente normalizadas; entonces éste publicó 12 reglas que un verdadero sistema relacional debería tener aunque en la práctica algunas de ellas son difíciles de realizar. Un sistema podrá considerarse "más relacional" cuanto más 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 información, toda la información en la base de datos es representada unidireccionalmente, por valores en posiciones de las columnas dentro de filas de tablas. Toda la información en una base de datos relacional se representa explícitamente en el nivel Lógico exactamente de una manera: con valores en tablas.  Regla 2: la regla del acceso garantizado, todos los datos deben ser accesibles sin ambigüedad. Esta regla es esencialmente una nueva exposición del requisito
  • 18.
    fundamental para lasllaves primarias. Dice que cada valor escalar individual en la base de datos debe ser lógicamente direccionable especificando el nombre de la tabla, la columna que lo contiene y la llave primaria.  Regla 3: Tratamiento sistemático de valores nulos, el sistema de gestión de base de datos debe permitir que haya campos nulos. Debe tener una representación de la "información que falta y de la información inaplicable" que es sistemática, distinto de todos los valores regulares.  Regla 4: catálogo dinámico en línea basado en el modelo relacional, el sistema debe soportar un catálogo en línea, el catálogo relacional debe ser accesible a los usuarios autorizados. Es decir, los usuarios autorizados deben poder tener acceso a la estructura de la base de datos (catálogo).  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 definición de datos, operaciones de manipulación de datos (actualización así como la recuperación), seguridad e integridad y operaciones de administración de transacciones.  Regla 6: regla de actualización, todas las vistas que son teóricamente actualizables deben ser actualizables por el sistema.  Regla 7: alto nivel de inserción, actualización y borrado, permitiendo el sistema realizar manipulación de datos de alto nivel, es decir, sobre conjuntos de tuplas. Esto significa que los datos no solo se pueden recuperar de una base de datos relacional de filas múltiples y/o de tablas múltiples, sino también pueden realizarse inserciones, actualización y borrados sobre varias tuplas y/o tablas al mismo tiempo (no sólo sobre registros individuales).  Regla 8: independencia física de los datos, los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico cuando quiera que se realicen cambios en las representaciones de almacenamiento o métodos de acceso.  Regla 9: independencia lógica de los datos, los cambios al nivel lógico (tablas, columnas, filas, etc.) no deben requerir un cambio a una solicitud basada en la estructura. La independencia de datos lógica es más difícil de lograr que la independencia física de datos.  Regla 10: independencia de la integridad, las limitaciones de la integridad se deben especificar por separado de los programas de la aplicación y se
  • 19.
    almacenan en labase de datos. Debe ser posible cambiar esas limitaciones sin afectar innecesariamente las aplicaciones existentes.  Regla 11: independencia de la distribución, la distribución 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 versión 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 subversión, 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 limitación de integridad. Esto es debido a que existen sistemas anteriormente no relacionales que añadieron una interfaz relacional, pero con la interfaz nativa existe la posibilidad de trabajar no relacionalmente.
  • 20.
    BIBLIOGRAFIA Barker, Richard. Elmodelo entidad-relación. CASE*METHODTM. Universidad Pontifica de Salamanca. Madrid, España. Publicado 1990. [En línea] [Citado 23 de octubre de 2015]. Disponible en internet: https://books.google.com.co/books?id=hbOTo05ddxAC&pg=PA11&hl=es&sourc e=gbs_toc_r&cad=3#v=onepage&q&f=false García. Emiliano. Forma normal 123. ACADEMIA.EDU. [en línea] [Citado 23 de octubre de 2015]. Disponible en internet: http://www.academia.edu/8400539/Forma_normal_1_2_3 ORACLE. ¿Qué es Oracle?. [En línea] [Citado 23 de octubre de 2015]. Disponible en internet: https://iessanvicente.com/colaboraciones/oracle.pdf WIKIPEDIA. Modelo relacional. Modificado 22 de octubre de 2015. [En línea] [Citado 23 de octubre de 2015]. Disponible en internet: https://es.wikipedia.org/wiki/Modelo_relacional WIKIPEDIA. 12 Reglas de Codd. Modificada 19 de octubre de 2015. [En línea] [Citado 23 de octubre de 2015]. Disponible en internet: https://es.wikipedia.org/wiki/12_reglas_de_Codd