El documento presenta un informe de un proyecto realizado por dos estudiantes para la profesora Ing. Carla V. Leal del Instituto Universitario Politécnico “Santiago Mariño”. Incluye los nombres y cédulas de identidad de los estudiantes y la información básica sobre la institución educativa.

1. Integrantes:
Jorge Ng CI:25.492.631
Eder Perozo CI:20.458.782
Profesora: Ing. Carla V. Leal C. MSc.
REPÚBLICA BOLIVARIANA DE
VENEZUELA
MINISTERIO DEL PODER POPULAR PARA
LA
EDUCACIÓN UNIVERSITARIA
INSTITUTO UNIVERSITARIO POLITECNICO
“SANTIAGO MARIÑO”
EXTENSIÓN COL-SEDE CIUDAD OJEDA

2. Representa una “cosa”, "objeto" o "concepto" del mundo
real con existencia independiente, es decir, se diferencia
únicamente de otro objeto o cosa, incluso siendo del mismo
tipo, o una misma entidad.
Algunos Ejemplos:
 Una persona. (Se diferencia de cualquier otra persona,
incluso siendo gemelos).
 Un automóvil. (Aunque sean de la misma marca, el
mismo modelo,..., tendrán atributos diferentes, por
ejemplo, el número de chasis).
 Una casa (Aunque sea exactamente igual a otra, aún se
diferenciará en su dirección).

3. Los atributos son las características que definen o
identifican a una entidad. Estas pueden ser muchas, y
el diseñador solo utiliza o implementa las que
considere más relevantes.
A la colección de entidades «alumnos», con el
siguiente conjunto de atributos en común, (id, nombre,
edad, semestre), pertenecen las entidades:
(1, Sophia, 15 años, 2)
(2, Josefa, 19 años, 5)
(3, Carlos, 20 años, 2)

4. Describe cierta dependencia entre entidades o permite
la asociación de las mismas.
Si tenemos dos entidades, CLIENTE y HABITACIÓN,
podemos entender la relación entre ambas al tomar un
caso concreto (ocurrencia) de cada una de ellas.
Entonces, podríamos tener la ocurrencia Habitación
502, de la entidad HABITACIÓN y la ocurrencia
Henry Johnson McFly Bogard, de la entidad CLIENTE,
entre las que es posible relacionar que la habitación
502 se encuentra ocupada por el huésped de nombre
Henry Johnson McFly Bogard.

5. Es una unidad mínima o ítem aislado que por si
solo no significa nada, es la unidad mínima
semántica

6. Es un conjunto de conceptos que pueden servir para
describir la estructura de una Base de Datos; tipo de datos,
las relaciones y que deben cumplirse para esos datos. Por
lo general los modelos de datos contienen además un
conjunto de operaciones básicas para especificar lecturas y
actualizaciones de la base de datos.
Son modelos de datos de muy alto nivel
En general se concentran en las estructuras y restricciones
de integridad
Suelen tener una representación gráfica asociada
Ejemplos:
Modelo Entidad-Relación (1976)
Modelo ER Extendidos (80’s y 90’s)

7. Es una herramienta para el modelado de datos que permite
representar las entidades relevantes de un sistema de
información así como sus interrelaciones y propiedades.
El modelado de datos no acaba con el uso de esta técnica. Son
necesarias otras técnicas para lograr un modelo directamente
implementable en una base de datos.
Brevemente: permite mostrar resultados entre otras entidades
pertenecientes a las existentes de manera que se encuentre la
normatividad de archivos que se almacenarán
Transformación de relaciones múltiples en binarias.
Normalización de una base de datos de relaciones (algunas
relaciones pueden transformarse en atributos y viceversa).
Conversión en tablas (en caso de utilizar una base de datos
relacional).

9. Si bien las Bases de Datos no son todas iguales, podemos nombrar algunos componentes
comunes:
Tablas: comprende definición de tablas, campos, relaciones e índices. Es el componente
principal de las Bases de Datos Relacionales.
Formularios: se utilizan principalmente para actualizar datos.
Consultas: se utilizan para ver, modificar y analizar datos.
Informes: se utilizan para presentar los datos en formato impreso.
Macros: conjunto de instrucciones para realizar una operación determinada.

10. Un modelo de datos debe especificar las asociaciones existentes entre las entidades. Estas asociaciones son las
relaciones entre entidades. Por ejemplo, la frase "los clientes compran productos" nos dice que hay dos entidades,
"Clientes" y "Productos", que están relacionadas por "comprar".
La gran mayoría de las asociaciones son binarias, como "los clientes compran productos" o "los empleados venden
productos". Entre las dos hay una asociación ternaria implícita: "los empleados venden productos a los clientes". Con
las dos asociaciones binarias independientemente no podríamos saber a qué clientes se han vendido los productos
que ha vendido un cierto empleado: en este caso necesitamos de la asociación ternaria.
Las asociaciones entre dos entidades cualesquiera pueden ser de tres tipos: uno-a-uno, uno-a-muchos y muchos-a-
muchos.
Asociaciones uno-a-uno: Si es cierto que cualquier ejemplar de la entidad X se puede asociar con tan sólo un ejemplar
de la entidad Y, entonces decimos que la asociación es uno-a-uno. Cuando elegimos una asociación uno-a-uno
debemos asegurarnos de que o bien se mantiene la asociación en todo momento, o en caso de que cambie no nos
interesan los valores pasados.
Por ejemplo: si asumimos que en los despachos de un edificio hay uno por persona, entonces la asociación será uno-
a-uno. Pero esta asociación sólo es cierta en un momento dado. A lo largo del tiempo, se irán asignando diferentes
empleados en el edificio. Habrá que valorar si el mantenimiento de esta información es útil en nuestro modelo o no.
Asociaciones uno-a-muchos: Es el tipo de asociación más común, donde un solo ejemplar de una entidad se puede
asociar con cero, uno o muchos ejemplares de otra entidad. Por ejemplo, una persona puede tener varios números de
teléfono.
Asociaciones muchos-a-muchos: Los clientes compran en muchas tiendas, una tienda tiene muchos clientes. Como
este tipo de relaciones no se puede modelar directamente en una base de datos relacional, se modela usando una
tabla intermedia que tenga una asociación uno-a-muchos con cada uno de los participantes originales. Por ejemplo,
un pedido puede tener muchos tipos de confección, y un tipo de confección puede aparecer en varios pedidos.

11. Asociaciones uno-a-uno
Asociaciones uno-a-muchos
Asociaciones muchos-a-muchos

12. La normalización de bases de datos es un proceso que consiste en
designar y aplicar una serie de reglas a las relaciones obtenidas tras el
paso del modelo entidad-relación al modelo relacional.
Las bases de datos relacionales se normalizan para:
Evitar la redundancia de los datos.
Disminuir problemas de actualización de los datos en las tablas.
Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relación,
aunque para que una tabla sea considerada como una relación tiene
que cumplir con algunas restricciones:
Cada tabla debe tener su nombre único.
No puede haber dos filas iguales. No se permiten los duplicados.
Todos los datos en una columna deben ser del mismo tipo.

13. Es el documento que contiene la descripción de los pasos
que deben seguirse en la realización de las funciones de
una o más unidades del sistema. El manual incluye
además las tablas y relaciones que intervienen en la base
de datos. Suelen contener información y ejemplos de
formularios, autorizaciones o documentos necesarios, y
cualquier otro dato que pueda auxiliar al correcto
desarrollo de las actividades del usuario. En él se
encuentra registrada y transmitida sin distorsión la
información básica referente al funcionamiento de todo el
sistema, facilita las labores de auditoria, la evaluación y
control interno y su vigilancia, la conciencia en los
empleados y en sus jefes de que el trabajo se está
realizando o no adecuadamente

15. 1. Definición del problema
2. Descripción funcional
3. Restricciones
4. Diagramas de flujo de datos
5. Modelo de Modelo de datos
6. Diccionario de datos
7. Casos de uso
8. Documentos adicionales

16. Las tareas a realizar en el diseño lógico son las
siguientes:
1. Identificar las entidades.
2. Identificar las relaciones.
3. Identificar los atributos y asociarlos a entidades y
relaciones.
4. Determinar los dominios de los atributos.
5. Determinar los identificadores.
6. Determinar las jerarquías de generalización (si las
hay).
7. Dibujar el diagrama entidad-relación.
8. Revisar el esquema lógico con el usuario.

17. Las tareas a llevar a cabo durante este proceso son:
- Convertir entidades en tablas físicas. Cuando la entidad es fuerte se convierte en una tabla.
- Escoger qué atributos se utilizarán para las columnas de las tablas y en qué tablas deben ir.
- Escoger los nombres finales de las columnas, en ocasiones abreviándolos. Esta tarea es
importante en bases de datos que limitan el tamaño de nombres de columnas.
- Escoger qué columnas se transformarán en claves de identificación de la tabla.
- Escoger también qué columnas serán índices y de esta manera volver más eficiente la
búsqueda de información en las consultas SQL sobre estas.
- Identificar las vistas a definirse en las tablas. Una vista es una forma alternativa para
describir los datos que existen en una o más tablas.
- Resolver las relaciones (n:m ó muchos a muchos) entre entidades. Usualmente se crea una
tabla extra que contiene las claves de ambas tablas relacionadas.
- Aplicar cierta desnormalización, dado que las reglas de normalización no consideran el
rendimiento de la base de datos. Por lo que, en ocasiones, cierta desnormalización es
necesaria para un funcionamiento más eficiente.

18.  https://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n
 https://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_
de_datos
 https://en.wikipedia.org/wiki/Associative_entity
 https://es.wikipedia.org/wiki/Manual_de_procedimientos
 http://www3.uji.es/~mmarques/f47/teoria/tema6.pdf
 http://dis.um.es/~lopezquesada/documentos/IES_1415/LMSGI
/curso/xhtml/html16/doc/bd2.pdf
 http://www.alegsa.com.ar/Dic/dise%C3%B1o_fisico_de_bases_
de_datos.php