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&source=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