Anda di halaman 1dari 6

UNIVERSIDAD DOMINICANA 0&M UN IVERSIDAD DOMINICANA

Pratica(III)

Santo domingo, D.N FUNDADA EL 12 DE ENERO 1966

Sustentado por; Ostin dicson Matricula; 07-eisn-1-114 Profesor: VICIOSO VICTOR Asignatura Base de datos Pratica(II)

3.1 vision general del proceso de diseo de una base de datos.


El diseo de una base de datos suele descomponerse en tres grandes fases (diseo conceptual, lgico y fsico), lo que permite reducir la complejidad que entraa el diseo, a la vez que ayuda a alcanzar los dos principales objetivos que tienen las bases de datos: Ser una representacin fidedigna del mundo real, Ser un servidor operacional y eficiente de los datos. El diseo conceptual parte de la especificacin de requerimientos, y produce como resultado el esquema conceptual de la base de datos. Un esquema conceptual es una descripcin a alto nivel de la estructura de la base de datos, independientemente de la eleccin del equipamiento y del Sistema Gestor de Base de Datos (en adelante referido como SGBD) que se usen para la implementacin de la base de datos. El diseo lgico parte del esquema conceptual y genera el esquema lgico. Un esquema lgico es la descripcin de la estructura de la base de datos que puede procesarse por un SGBD. Una vez elegido el modelo lgico, pueden existir un conjunto de esquemas lgicos equivalentes al mismo esquema conceptual. La meta del diseo lgico es producir el esquema lgico ms eficiente con respecto a las operaciones de consulta y actualizacin. El diseo fsico toma como punto de partida el esquema lgico y como resultado produce el esquema fsico. Un esquema fsico es una descripcin de la implementacin de la base de datos en memoria secundaria; describe las estructuras de almacenamiento y los mtodos de acceso para acceder a los datos de una manera eficiente. Por ello, el diseo fsico se genera para un SGBD y un entorno fsico determinado.

3.2 Restricciones
Una restriccin es una condicin que obliga el cumplimiento de ciertas condiciones en la base de datos. Algunas no son determinadas por los usuarios, sino que son inherentemente definidas por el simple hecho de que la base de datos sea relacional. Algunas otras restricciones las puede definir el usuario, por ejemplo, usar un campo con valores enteros entre 1 y 10. Las restricciones proveen un mtodo de implementar reglas en la base de datos. Las restricciones restringen los datos que pueden ser almacenados en las tablas. Usualmente se

definen usando expresiones que dan como resultado un valor booleano, indicando si los datos satisfacen la restriccin o no. Las restricciones no son parte formal del modelo relacional, pero son incluidas porque juegan el rol de organizar mejor los datos. Las restricciones son muy discutidas junto con los conceptos relacionales.

3.3 Diagrama entidad y relacin


Diagrama Entidad-Relacin (E-R). Tambin conocido como "diagrama de Chen". Estos diagramas modelizan el problema mediante entidades asociadas por relaciones. Adoptan la forma de grafos donde los datos se relacionan mediante flechas. El diagrama E-R no depende del modelo de datos. Propuesto por Chen a mediados de los aos setenta como medio de representacin conceptual de los problemas y para representar la visin de un sistema de forma global. Fsicamente adopta la forma de un grafo escrito en papel al que se denomina diagrama Entidad-Relacin. Sus elementos fundamentales son las entidades y las relaciones. Una entidad caracteriza a un tipo de objeto, real o abstracto, del problema a modelizar. Toda entidad tiene existencia propia, es distinguible del resto de las entidades, tiene nombre y posee atributos definidos en un dominio determinado. Una entidad es todo aquello de lo que se desea almacenar informacin. En el diagrama E-R las entidades se representan mediante rectngulos. Una relacin es una asociacin o relacin matemtica entre varias entidades. Las relaciones tambin se nombran. Se representan en el diagrama E-R mediante flechas y rombos. Cada entidad interviene en una relacin con una determinada cardinalidad. La cardinalidad (nmero de instancias o elementos de una entidad que pueden asociarse a un elemento de la otra entidad relacionada) se representa mediante una pareja de datos, en minsculas, de la forma (cardinalidad mnima, cardinalidad mxima), asociada a cada uno de las entidades que intervienen en la relacin. Son posibles las siguientes cardinalidades: (0,1), (1,1), (0,n), (1,n), (m,n). Tambin se informa de las cardinalidades mximas con las que intervienen las entidades en la relacin. El tipo de relacin se define tomando los mximos de las cardinalidades que intervienen en la relacin. Hay cuatro tipos posibles:

1. Una a una (1:1). En este tipo de relacin, una vez fijado un elemento de una entidad se conoce la otra. Ejemplo: nacin y capital. 2. Una a muchas (1:N). Ejemplo: cliente y pedidos. 3. Muchas a una (N:1). Simetra respecto al tipo anterior segn el punto de vista de una u otra entidad. 4. Muchas a muchas (N:N). Ejemplo: personas y viviendas.

3.4 Aspecto del diseo entidad y relacin.


Uno de los aspectos ms complicados del diseo de bases de datos es el hecho de que los diseadores, programadores y usuarios finales tienden a contemplar los datos y su utilizacin de diferentes maneras Los modelos intentan crear un lenguaje comn no tcnico libre de ambigedades El Modelo Entidad-Relacin es una tcnica de modelado de tipo arriba-abajo que comienza identificando los datos ms importante.

3.5Conjunto de entidad dbil


un tipo de entidad dbil es aquella cuya existencia depende de otro tipo de entidad. Cada instancia de la entidad no puede identificarse de manera unvoca utilizando los atributos asociados con ese tipo de entidad.

3.6 caracteristicas del modelo E-R extendido.


Aunque los conceptos bsicos de E-R pueden modelar la mayora de las caractersticas de las bases de datos, algunos aspectos de una base de datos pueden ser ms adecuadamente expresados mediante ciertas extensiones del modelo E-R bsico. En este apartado se discuten las caractersticas E-R extendidas de especializacin, generalizacin, conjuntos de entidades de nivel ms alto y ms bajo, herencia de atributos y agregacin.

3.7 Diseo de una base de datos para un banco.


Lo importante no es que lo copies, sino que los tomes como una gua. Por empezar, el decir "base de datos para un banco" es muy general. La pregunta que deberamos hacerte es QU del banco se desea guardar? Con que fin, cual es su objetivo? que se espera? Para qu?

No es lo mismo el diseo del banco de fulanito que el diseo de la base de datos que posee por decir algo extremo... el de banco nacional, o el que pueda llegar a manejar incluso el FMI.

No existen bases de datos genricas. El diseo debe ajustarse a las necesidades y requisitos. Por ello es que no hay diseo nico e infalible. Te recomiendo que analices adecuadamente el alcance del proyecto y definas los lmites. En base a ello definirs el diseo. Espero que entiendas que por ms ejemplos, es posible que ninguno acabe resolviendo todas las dudas.

Si lo que buscas es ayuda y asistencia, recomendaciones o guas, explica y brinda detalles. Porque de forma tan abstracta y general es imposible proponer un diseo 100% para lo que necesitas y ests buscando. Cuanto mucho podramos descubrir lo mnimo e indispensable, el factor comn de cualquier base de datos diseada para un banco, pero de all en ms el anlisis e interpretacin del contexto tendr la ltima palabra

3.8 Reduccion a esquema relacionales


En general, el objetivo del diseo de una base de datos relacional es generar un conjunto de esquemas de relaciones que permitan almacenar la informacin con un mnimo de redundancia, pero que a la vez faciliten la recuperacin de la informacin. Una de las tcnicas para lograrlo consiste en disear esquemas que tengan una forma normal adecuada. Para determinar si un esquema de relaciones tiene una de las formas normales se requiere mayor informacin sobre la empresa del "mundo real" que se intenta modelar con la base de datos. La informacin adicional la proporciona una serie de limitantes que se denominan dependencias de los datos.

El esquema conceptual contiene una descripcin detallada de los requerimientos de informacin de los usuarios, y contiene descripciones de los tipos de datos, relaciones entre ellos y restricciones.

3.9 Lenjuaje de modelado unificado UML


El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la sucesin de una serie de mtodos de anlisis y diseo orientadas a objetos que aparecen a fines de los 80's y

principios de los 90s.UML es llamado un lenguaje de modelado, no un mtodo. Los mtodos consisten de ambos de un lenguaje de modelado y de un proceso. El UML , fusiona los conceptos de la orientacin a objetos aportados por Booch, OMT y OOSE (Booch, G. et al., 1999). UML incrementa la capacidad de lo que se puede hacer con otros mtodos de anlisis y diseo orientados a objetos. Los autores de UML apuntaron tambin al modelado de sistemas distribuidos y concurrentes para asegurar que el lenguaje maneje adecuadamente estos dominios. El lenguaje de modelado es la notacin (principalmente grfica) que usan los mtodos para expresar un diseo. El proceso indica los pasos que se deben seguir para llegar a un diseo. La estandarizacin de un lenguaje de modelado es invaluable, ya que es la parte principal del proceso de comunicacin que requieren todos los agentes involucrados en un proyecto informtico. Si se quiere discutir un diseo con alguien ms, ambos deben conocer el lenguaje de modelado y no as el proceso que se sigui para obtenerlo.

Anda mungkin juga menyukai