• Author / Uploaded
• LEONARDO VICTORIA

Citation preview

“UNIVERSIDAD TECNOLÓGICA DE MÉXICO”   ALUMNO: LEONARDO ENRIQUE VICTORIA SOSA

MATRICULA: 19593541

PROFESOR: ALMA MARTHA RÍOS ALCANTARA

CARRERA: ING. EN SOFTWARE Y REDES

MATERIA: MODELOS DE BASES DE DATOS

MODULO: ON-LINE

SEMANA: 2

ACTIVIDAD: ENTREGABLE 1

FECHA: 07/02/2020

CICLO ESCOLAR: 20-1

“Ciencia y técnica con humanismo”

Fundamentos de las Bases de datos relacionales y Diseño de base de datos relacionales Contenido ENTREGABLE 1. Fundamentos de las Bases de datos relacionales y Diseño de base de datos relacionales...................................................................................................................3 1.

Objetivo.................................................................................................................................3

2.

Fundamentos de las Bases de datos relacionales..........................................................3 Modelo Relacional......................................................................................................................3 Restricciones del lenguaje..........................................................................................................4 SQL.Structured Query Language para SGBD relacional..............................................................5 Clasificación de las sentencias SQL.............................................................................................6 Lenguaje de definición de datos-Data Definition Language. DML..............................................7 Lenguaje de manipulación de datos-Data Manioulation Laguage, DML.....................................7 Lenguaje de control de transaciones –Transactión Control Language, TCL................................7 Lenguaje de control de datos- data control Language,DCL........................................................7 SQL dinámico..............................................................................................................................8

3.

Diseño de Base de Datos Relacionales...........................................................................9 Fases y pautas del diseño de base de datos...............................................................................9 Dependencias Funcionales.......................................................................................................10 Reglas de transformación del esquema E/R al esquema relacional.........................................11 Normalización..........................................................................................................................12 Documentación y manteamiento de esquemas.......................................................................13

4.

Conclusión..........................................................................................................................14

5.

Bibliografía..........................................................................................................................14

ENTREGABLE 1. Fundamentos de las Bases de datos relacionales y Diseño de base de datos relacionales 1. Objetivo.  Tener claras las bases para la realización de un proyecto de base de datos.  Conocer el procedimiento a seguir para el diseño de una base de datos.  Definir los conceptos pertenecientes a las bases de datos.  Adquirir conocimiento acerca de esquemas, implementación de las bases de datos.

diagramas

para

la

2. Fundamentos de las Bases de datos relacionales Modelo Relacional. Consistente en el almacenamiento de datos en tablas compuestas por filas, o tuplas, y columnas o campos. Es una colección de tablas, también llamadas relaciones, se utiliza principalmente para usuarios inexpertos en base de datos por su fácil utilización, por esta razón es el modelo que se utiliza mas comúnmente. Componentes del modelo relacional.  Tabla. Se le denomina tabla a la relación que se establecen entre los datos almacenados.  Filas. Denominada tupla, aquí se describen las configuraciones de los elementos (datos) de la tabla, los elementos de la relación establecida por la tabla. Nunca duplicadas. Mínima unidad de borrado. Registro lógico. Su número varí según se realicen operaciones de inserción y borrado en la tabla. o Pueden estar dispuestas en cualquier orden. o o o o



Columnas. También denominadas campos, en estas encontraremos los atributos y valores de nuestra base datos, de igual manera se determina el dominio.

o o o o o

Nombre único en cada tabla. Espacio de valores o dominio. Valor nulo: indica valor desconocido o no aplicable. Captura opcional (puede tomar valores nulos) u obligatoria. Su número es a priori fijo.

 Claves. Son elementos únicos para poder diferenciar los datos entre sí, al igual que las relaciones.  Primarias. Son las columnas que son los atributos, de acuerdo al tipo de relación que se ah definido en la tabla de base de datos.  Secundarias o externas. Son las claves que se definen para cada una de las claves primarias.

Restricciones del lenguaje En este modelo existen 3 tipos de restricciones que se mencionaran a continuación.  Integridad de la clave. Ningún atributo de una clave candidata puede tomar valores nulos.  Integridad de referencia o referencial. En una tabla existe un atributo definido con el mismo dominio, aunque no obligatoriamente con igual nombre, y que es parte de su clave primaria.  Otras restricciones de acuerdo con la semántica concreta del problema. o 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 Complejas. Condiciones sobre valores de los atributos en función de valores de otros atributos de esa u otras tablas.

SQL.Structured Query Language para SGBD relacional El lenguaje SQL en relación con el modelo relacional para los SGBD relacionales, puedo representar casi todos los elementos, exceptuando alguno de ellos. Cabe mencionar que la manipulación de datos es mayor en SQL que en los SGBD relacionales, mediante el algebre relacional, por esto cumplen efectivamente con la funcionalidad del modelo relacional. El modelo relaciona se compone de:       

Parte Estática. Dominios. Atributos. Relaciones. Reglas de Integridad. Parte Dinámica. Algebra Relacional.

Las operaciones típicas de las BD como consultar, crear, actualizar o borrar datos se realizan por medio de las llamadas sentencias SQL (SQL statements), una combinación de órdenes SQL, semánticamente vinculadas al inglés y por este motivo bastante elocuentes. A continuación, se muestra una tabla en relación en términos de SQL con el modelo relacional. Modelo de datos relacional Relación Atributo Tupla

SQL Tabla Columna Fila

Ejemplo de consulta en SQL: SELECT columna FROM tabla WHERE columna = valor; Se utiliza SELECT en primer lugar para ordenar al SGBD relacional que consulte ciertos datos. A continuación, se definen los datos que se quieren consultar proporcionando tanto la tabla como la columna que deseamos seleccionar. Con WHERE se integra una condición en la sentencia SQL porque no se quiere abrir todos los valores en esta columna, sino solo el valor de un determinado registro.

Clasificación de las sentencias SQL

SENTENCIA DML

DDL

DCL

PLSQL

Manipulación SELECT INSERT DELETE UPDATE

de

datos

Definición de datos CREATE TABLE DROP TABLE ALTER TABLE CREATE VIEW DROP VIEW CREATE INDEX DROP INDEX CREATE SYNOYM DROP SYNONYM

DESCRIPCIÓN Recupera datos de la base de datos. Añade nuevas filas de datos a la base de datos. Suprime filas de datos de la base de datos. Modifica datos existentes en la base de datos. Añade una nueva tabla a la base de datos. Suprime una tabla de la base de datos. Modifica la estructura de una tabla existente. Añade una nueva vista a la base de datos. Suprime una vista de la base de datos. Construye un índice para una columna. Suprime el índice para una columna. Define un alias para un nombre de tabla. Suprime un alias para un nombre de tabla.

Control de acceso GRANT REVOKE Control de transacciones COMMIT ROLLBACK

Concede privilegios de acceso a usuarios. Suprime privilegios de acceso a usuarios

SQL Programático DECLARE OPEN FETCH CLOSE

Define un cursor para una consulta. Abre un cursor para recuperar resultados de consulta. Recupera una fila de resultados de consulta. Cierra un cursor.1

Finaliza la transacción actual. Aborta la transacción actual.

2

Lenguaje de definición de datos-Data Definition Language. DML

1

5 DE MAYO DE 2012. Bases de Datos Jolunf - Design by Templateure - IMC..Recuperado de: http://basededatosysql.blogspot.com/2012/05/clasificacionde-sentencias-y-algo-mas.html 2

5 DE MAYO DE 2012. Bases de Datos Jolunf - Design by Templateure - IMC..Recuperado de: http://basededatosysql.blogspot.com/2012/05/clasificacionde-sentencias-y-algo-mas.html

Este lenguaje les permite a los usurarios de las bases de datos cumplir con las tareas de estructuras donde se almacenarán los datos, de igual forma los procedimientos y funciones de consulta. Lenguaje de manipulación de datos-Data Manioulation Laguage, DML Permite a los usuarios introducir datos a la base de datos que quedaran almacenado, para posteriormente realizar consultas y modificaciones de estos mismos. Lenguaje de control de transaciones –Transactión Control Language, TCL Este lenguaje permite al usuario manejar transacciones de la base de datos relacional. Los comandos a implementar son: BEGIN TRANSACTION. Para comenzar una transacción. COMMIT. Para grabar todos los cambios de la base de datos. ROLLBACK. Para deshacer todos los cambios de la transacción. En cada motor puede cambiar ligeramente la manera de definirlos, pero en lo general es lo mismo: 1.- Se define el inicio de las transacciones. BEGIN TRANS, BEGIN TRANSACTION. 2.- Se realizan todas las operaciones necesarias. UPDATE, INSERT, DELETE. 3.- Se intentan grabar todas las modificaciones. COMMIT. 4.- Si se detecta un error de puede borrar todo antes del punto 1. ROLLBACK. Lenguaje de control de datos- data control Language,DCL Estos comandos permiten al usuario administrar y gestionar los permisos de la base de datos, es decir, controlar el acceso a los objetos.  

GRANT, permite otorgar permisos. REVOKE, elimina los permisos que previamente se han concedido.

SQL dinámico

Las sentencias dinámicas se refieren a aquellas sentencias que son generadas durante la ejecución de un script. Las sentencias dinámicas siempre van acompañadas de la palabra EXECUTE (Transact-SQL) con strings y variables. SQL Server determina el valor de las variables conforme se va ejecutando el script. Implementación de SQL dinámico. Procesa la mayoría de las sentencias SQL dinámicas por medio de la sentencia EXECUTE IMMEDIATE. Si la sentencia SQL dinámica es una instrucción SELECT que devuelve varias filas, SQL dinámico nativo le ofrece las siguientes opciones: • Utilice la sentencia EXECUTE IMMEDIATE con la cláusula BULK COLLECT INTO. • Utilice las sentencias OPEN-FOR, FETCH y CLOSE. Uso de SQL Dinámico Nativo. SQL dinámico nativo procesa la mayoría de las sentencias SQL dinámicas por medio de la sentencia EXECUTE IMMEDIATE. Si la sentencia SQL dinámica es una instrucción SELECT que devuelve varias filas, SQL dinámico nativo le ofrece las siguientes opciones: • Utilice las sentencias EXECUTE IMMEDIATE con la cláusula BULK COLLECT INTO. • Utilice las sentencias OPEN-FOR, FETCH y CLOSE. Puede utilizar variables Bind como parámetros dinámicos en las sentencias EXECUTE IMMEDIATE y OPEN. SQL Dinámico Nativo incluye las siguientes capacidades: • Define la sentencia SQL dinámica. • PL/SQL soporta instancias Bind de cualquier tipo de datos SQL. • Maneja variables Bind con modo: IN, IN OUT y OUT que están enlazadas por posición, no por nombre. La instrucción EXECUTE IMMEDIATE ejecuta una sentencia SQL dinámica o un bloque PL/SQL anónimo. Puede usarla para emitir sentencias SQL que no se pueden incluir directamente en PL/SQL o para generar sentencias en las que no se conocen los nombres de tabla, cláusulas WHERE, etc.

3. Diseño de Base de Datos Relacionales

Fases y pautas del diseño de base de datos Existen 3 fases para la implementación y diseño de una base de datos. 1.- Diseño Conceptual. Esta fase contiene los elementos de nuestra base de datos y la relación que existe entre cada uno de ellos, en este diseño a cada entidad se le asignaran sus atributos y se resaltaran los atributos principales, por ultimo se establecen las relaciones entre las entidades. Principalmente se utiliza el diagrama de entidad relación.

NOMBRE TALLA

PERSONA

VENDE

ROPA

ID DE VENTAS PRECIO

2.- Diseño Lógico. En esta parte se tabula el diseño conceptual, es decir se desarrolla y se especifica las clases, entidades, con sus atributos, especificando de la misma manera que en el diseño conceptual las relaciones que existen entre cada uno de ellos, se especifican las claves, filas y columnas. Principalmente se utiliza el diagrama de clases UML. CLASES nombre

Persona

atributos

Nombre Id. De ventas

operaciones

responsabilidades

3.- Diseño físico

Alta Baja -Solicitar pedidos -Presentar documentación

Se detalla más nuestra base de datos uy sus dominios, cuales índices debemos crear para optimizar las consultas, entre otros. Aquí ya escribimos nuestro SQL para plasmar todo nuestro diseño en el motor de bases de datos elegido. CREATE TABLE persona ( Id AUTOINCREMENT, Nombre VARCHAR (50) NOT NUL, Edad INT, CONSTRAINT id_ventas PRIMARY KEY (id) ); Dependencias Funcionales Estas dependencias particularmente son de tipo restrictivas, permiten expresar hechos acerca de la realidad que se está modelando con la BD. Es una restricción entre dos conjuntos de atributos de la base de datos. Una dependencia funcional, denotada por X→Y, entre dos conjuntos de atributos X e Y que son subconjuntos de R, especifica una restricción en las posibles tuplas que pueden formar un estado de relación r de R. La restricción dice que dos tuplas t1 y t2 en r tales que cumplen que t1[X] = t2[X], deben cumplir también que t1[Y] = t2[Y]. 

Una dependencia funcional es una propiedad de la semántica o significado de los atributos.



Las dependencias funcionales deben mantenerse en todos los estados de relación r de R.



Los estados de relación r(R) que satisfacen la restricción de DF reciben el nombre de estados de relación legales.



Por tanto, el uso fundamental de las DFs es describir más en profundidad un esquema de relación R especificando restricciones de sus atributos que siempre deben cumplirse.



Ciertas DFs pueden especificarse sin hacer referencia a una relación específica.

Por ejemplo: En la relación préstamo se satisface número-préstamo cantidad. En el mundo real exigimos que cada préstamo tenga una única cantidad. Por tanto, imponemos la restricción de que se cumpla número-préstamo cantidad en esquema-préstamo. Reglas de transformación del esquema E/R al esquema relacional

1.- Todas las tablas E/R pasan a ser del tipo modelo racional. 2-. Absolutamente todas las relaciones del modelo pasan a ser E/R pasan a ser dominio de del modelo, al igual que las claves primarias y los atributos. 3.- En las relaciones (1, N) o (N,1), la clave primaria de la entidad 1, pasa como atributo de la entidad N. 4.- Los atributos multivalorados se transfieren a una nueva tabla del modelo relacional, donde la clave primaria es el atributo multivalorado. 5.- Si la relación (E/R) de (1, N) tiene un atributo, se convierte en una nueva tabla del modelo relacional. La clave primaria de (N) pasa como clave primaria de la nueva tabla, y la clave primaria (1) pasa como atributo de la nueva tabla, el atributo de la relación se convierte en atributo de la tabla.

Normalización El proceso de normalización de datos consiste en una serie de reglas que debe de cumplir nuestra base de datos para evitar la redundancia en los datos, disminuir 3

DaumierWebAndProgramming. Reglas de transformación del modelo E/R al modelo relacional. Recuperado de : https://daumindex.wordpress.com/2013/03/18/reglas-de-transformacion-del-modelo-er-al-modelorelacional-2/

problemas de actualización en las tablas y proteger la integridad de los datos. Después de haber realizado el modelo de entidad-relación. A continuación, se en listan las formas de normalización para una base de datos.  1F.- NO repetir campos en las tablas (atributos atómicos).  2F.- Se debe aplicar la 1FN. Cada campo de la tabla debe depender de una clave única, si tuviéramos alguna columna que se repite a lo largo de todos los registros, dichos datos deberían atomizarse en una nueva tabla.  3F.- Se debe aplicar la 1FN y 2FN. Los campos que NO son clave NO deben tener dependencias. Se debe aplicar la 1FN, 2FN y 3FN. Es una versión mejorada de la 3FN. Los campos que NO son clave NO deben tener dependencias. Los campos que NO dependan de la clave se deben eliminar.  4F.- Se debe aplicar la FNBC. La 4FN aplica únicamente para relaciones M a M, y nos ayuda a eliminar la redundancia de información generada por dicho tipo de relación.  5F.- En modelos muy grandes donde tenemos muchas relaciones y entidades, nos sugiere que una vez que hayamos terminado la normalización de nuestro modelo, lo revisemos una vez más en busca de posibles errores de lógica en la normalización, para efectos de nuestro ejemplo que es un modelo sencillo no aplicaremos la quinta forma normal. En algunos casos, es necesario considerar la desnormalización para mejorar el rendimiento. La desnormalización es la duplicación intencionada de columnas en varias tablas, lo cual aumenta la redundancia de datos. No debe suponerse automáticamente que todas las uniones tardan demasiado tiempo. La normalización es una técnica utilizada para diseñar tablas en las que las redundancias de datos se reducen al mínimo. Las primeras tres formas normales (1FN, 2FN y 3FN) son las más utilizadas. Desde un punto de vista estructural, las formas de mayor nivel son mejores que las de menor nivel, porque aquellas producen relativamente pocas redundancias de datos en la base de datos. En otras palabras, 3FN es mejor que 2FN y ésta, a su vez, es mejor que 1FN. Casi todos los diseños de negocios utilizan la 3FN como forma ideal.

Documentación y manteamiento de esquemas

La documentación para el mantenimiento de esquemas constituye el elemento de referencia para el programador que haya de realizar cambios o ampliaciones de la base de datos en el futuro. Los documentos que requieren para darle un buen seguimiento al mantenimiento de los esquemas son: 1.- El esquema conceptual global 2.-Ajustes de configuración y ubicación de archivos. 3.-Datos de contacto personal. 4.-Procedimientos de mantenimiento estándar y horarios. 5.- Procedimiento de recuperación de desastres. Mantenimiento.  Monitorización de las prestaciones del sistema. Si las prestaciones caen por

debajo de un determinado nivel, puede ser necesario reorganizar la base de datos.  Mantenimiento y actualización del sistema. Cuando sea necesario, los nuevos requisitos que vayan surgiendo se incorporarán al sistema, siguiendo de nuevo las etapas del ciclo de vida que se acaban de presentar.  Deben hacerse periódicamente copias de seguridad de la base de datos. El sistema debe estar siempre preparado para problemas graves de equipo y programas informáticos y de pérdida de datos. Para asegurar que se realicen copias de seguridad con regularidad los procedimientos deben ser lo más sencillos posible.  Dado que la base de datos evoluciona con el tiempo y se producen cambios en la tecnología de la información, el archivo de datos es fundamental para permitir la recuperación de los datos históricos almacenados en la estructura o el diseño anterior. El archivo de datos debe realizarse utilizando un medio no volátil (USB, Disco duro externo, Cloud) y un formato de datos independiente del sistema.  Como resultado de los mecanismos de retroinformación establecidos y para asegurarse de que el sistema de gestión de datos está logrando sus objetivos (es decir, que da respuesta a las necesidades de los clientes), deben llevarse a cabo evaluaciones periódicas con la presencia de representantes de los usuarios del sistema.  Se recomienda un programa continuado de evaluación del diseño para asegurar que el sistema aproveche los últimos avances de la tecnología de la información. Debe prestarse especial atención al establecimiento de procedimientos de actualización de los datos archivados de forma que se pueda seguir accediendo a los datos anteriores almacenados.

4. Conclusión En este entregable me quedo mas claro los fundamentos y requerimientos necesarios para lograr una buena implementación y diseño de base de datos, de igual manera en qué casos se podrían utilizar, pude analizar los diferentes tipos de elementos que la componen y cuando utilizar sus características. Pude comprender y analizar los diferentes tipos de lenguajes que existen para las bases de datos y determinar el más común que es SQL, es un lenguaje que se utiliza más comúnmente en las compañías, es muy amplio y es muy efectivo con los diferentes motores. SQL cumple con todos los requerimientos de los SGBDR. Sin embargo, como no permite representar el MR de forma completa, los SGBDR que utilizan SQL tampoco lo hacen. Como resultado, se tienen muchos SGBDR comercialmente difundidos que no soportan completamente el Modelo Relacional. Actualmente, las bases de datos han sido muy eficientes durante casi 40 años, sin embargo, siento que pueden actualizarse mejor a las nuevas tecnologías que existen y que vendrán. Las bases de datos en el ámbito de marketing son muy efectivas ya que se adecuan muy bien a las tablas, aun que su interfaz es muy sencilla y eso es favorable, también se pueden realizar consultas complejas.

5. Bibliografía A. de Miguel, M. Piottini: "Concepción y Diseño de bases de Datos: del modelo E/R al modelo Relacional", Addison- Wesley, 1993 PIATTINI, Mario. Diseño de Base de Datos Relacionales. Edit. Alfaomega. PIATTINI, Mario. Fundamentos y Modelos de Bases de Datos. Edit. Alfaomega Ramez A. Elmasri & Shamkant B. Navathe. “Fundamentos de Sistemas de Bases de Datos”. Tercera edición. AddisonWesley. 2002. SILBERSCHATZ, Abraham. Fundamentos de base de datos. Cuarta Edición. Edit. McGraw-Hill

Páginas web de consulta: 5 DE MAYO DE 2012. Bases de Datos Jolunf - Design by Templateure - IMC..Recuperado de: http://basededatosysql.blogspot.com/2012/05/clasificacion-de-sentencias-y-algo-mas.html

DaumierWebAndProgramming. Reglas de transformación del modelo E/R al modelo relacional. Recuperado de : https://daumindex.wordpress.com/2013/03/18/reglas-de-transformacion-delmodelo-er-al-modelo-relacional-2/