Base de Datos 2009
1. Diseño de Bases de Datos
1.1. Análisis
1.2. Modelo entidad / relación (E/R)
1.3. Modelo relacional
1.4. Lenguaje SQL y base de datos final
2. Diseño físico
3. Diseño conceptual
4. Diseño lógico
5. Características de una base de datos
6. Objetivos del Diseño de la Base de Datos
7. Almacenar Solo La Información Necesaria.
7.1. Normalizar la Estructura de las Tablas
7.2. Seleccionar el Tipo de Dato Adecuado
7.3. Utilizar Índices Apropiadamente
7.4. Usar Consultas REPLACE
7.5. Usar Una Versión Reciente de SQL
7.6. Usar Tablas Temporales
2
Base de Datos 2009
INTRODUCCIÒN.
Hoy en día las empresas manejan una gran cantidad de datos. Cualquier empresa que se precie
debe tener almacenados todos estos datos en una base de datos para poder realizarlos
mediante una aplicación profesional; sin esta funcionalidad resultaría imposible tratar y
manejar en su totalidad los datos que lleva a cabo la empresa y se perdería un tiempo y
dinero.
Uno de los pasos cruciales en la construcción de una aplicación que maneje una base de datos,
es sin duda, el diseño de la base de datos.
No importa la cantidad de registro que tengamos, es importante asegurarnos que nuestra base
de datos está correctamente diseñada para que tenga eficiencia y que se pueda seguir
utilizando por largo del tiempo.
3
Base de Datos 2009
1. Diseño de Bases de Datos
El objetivo principal del diseño de bases de datos es generar tablas que modelan los
registros en los que guardaremos nuestra información.
1. Análisis.
2. Diseño del modelo entidad / relación.
3. Diseño del modelo relacional.
4. Lenguaje SQL y base de datos final.
1.1. Análisis
Debemos comenzar estudiando a fondo el mundo real que deseamos representar en
la aplicación y base de datos.
A partir de este estudio, debemos crear el UD, que es simplemente la visión del
mundo real bajo unos determinados objetivos.
1.2. Modelo entidad / relación (E/R)
El diseñador debe concebir la base de datos en un nivel superior, abstrayéndose de
cualquier consideración técnica o de implementación en sistema, plataforma o
aplicación.
Para ello puede contar con la ayuda de un modelo de datos como el E/R, presentado
por Peter P. Chen. Con el podrá centrarse en la estructura lógica y abstracta de la
información, siendo capaz de representar toda la semántica del mundo real por
medio de entidades y relaciones.
1.3. Modelo relacional
El diseñador debe transformar el modelo E/R en el modelo relacional, teniendo muy
en cuenta la teoría de la normalización. Esta es una operación de cierta complejidad.
El modelo relacional, presentado por el Dr. E.F.Codd, fue revolucionario puesto que
consigue la independencia de las aplicaciones respecto a los datos.
Este modelo de datos esta basado en las teorías matemáticas de las relaciones,
haciendo que los datos se estructuren lógicamente en forma de relaciones -tablas.
Presenta beneficios como:
Sencillez y uniformidad: Al tener como resultado una colección de tablas, y
ser la tabla la estructura básica se da como resultado una gran uniformidad,
junto con la sencillez de los lenguajes de usuario que pueden operar con
ellas.
Flexibilidad: Ofreciendo a los usuarios los datos de la forma mas adecuada
a su aplicación.
Independencia del interfaz de usuario: El modo en el que se almacena los
datos no influye en su manipulación lógica.
4
Base de Datos 2009
1.4. Lenguaje SQL y base de datos final
Ahora solamente tendremos que codificar en lenguaje SQL el modelo relacional
expuesto anteriormente.
Para ello necesitaremos de:
LDD: Con el que (por ejemplo) codificar las sentencias para la creación de
las distintas tablas de la base de datos.
LMD: Para codificar las instrucciones (que por ejemplo) se encargarán de
realizar: consultas, adiciones, eliminaciones de registros.
2. Diseño físico
El diseño físico es el proceso de producir la descripción de la implementación de la base de
datos en memoria secundaria: estructuras de almacenamiento y métodos de acceso que
garanticen un acceso eficiente a los datos.
En general, el propósito del diseño físico es describir cómo se va a implementar físicamente el
esquema lógico obtenido en la fase anterior. Concretamente, en el modelo relacional, esto
consiste en:
Obtener un conjunto de relaciones (tablas) y las restricciones que se deben cumplir
sobre ellas.
Determinar las estructuras de almacenamiento y los métodos de acceso que se van a
utilizar para conseguir unas prestaciones óptimas.
Diseñar el modelo de seguridad del sistema.
3. Diseño conceptual
En esta etapa se debe construir un esquema de la información que se usa en la empresa,
independientemente de cualquier consideración física. A este esquema se le denomina
esquema conceptual. Al construir el esquema, los diseñadores descubren la semántica
(significado) de los datos de la empresa: encuentran entidades, atributos y relaciones. El
objetivo es comprender:
La perspectiva que cada usuario tiene de los datos.
La naturaleza de los datos, independientemente de su representación física.
El uso de los datos a través de las áreas de aplicación.
El esquema conceptual se puede utilizar para que el diseñador transmita a la empresa lo que
ha entendido sobre la información que ésta maneja. Para ello, ambas partes deben estar
familiarizadas con la notación utilizada en el esquema. La más popular es la notación del
modelo entidad-relación, que se describirá en el capítulo dedicado al diseño conceptual.
4. Diseño lógico
El diseño lógico es el proceso de construir un esquema de la información que utiliza la
empresa, basándose en un modelo de base de datos específico, independiente del SGBD
concreto que se vaya a utilizar y de cualquier otra consideración física.
5
Base de Datos 2009
En esta etapa, se transforma el esquema conceptual en un esquema lógico que utilizará las
estructuras de datos del modelo de base de datos en el que se basa el SGBD que se vaya a
utilizar, como puede ser el modelo relacional, el modelo de red, el modelo jerárquico o el
modelo orientado a objetos. Conforme se va desarrollando el esquema lógico, éste se va
probando y validando con los requisitos de usuario.
La normalización es una técnica que se utiliza para comprobar la validez de los esquemas
lógicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas
no tienen datos redundantes. Esta técnica se presenta en el capítulo dedicado al diseño lógico
de bases de datos.
5. Características de una base de datos
La velocidad de acceso,
El tamaño de la información,
El tipo de la información,
Facilidad de acceso a la información,
Facilidad para extraer la información requerida,
El comportamiento del manejador de bases de datos con cada tipo de información.
6. Objetivos del Diseño de la Base de Datos
Entre las metas más importantes que se persiguen al diseñar un modelo de bases de datos, se
encuentran las siguientes que pueden observarse en esta figura.
7. Almacenar Solo La Información Necesaria
Frecuentemente podemos generar algunos datos sobre la marcha sin tener que almacenarlos
en una tabla de una base de datos. En estos casos también tiene sentido hacer esto desde el
punto de vista del desarrollo de la aplicación.
7.1. Normalizar la Estructura de las Tablas
Uno de los objetivos de una estructura de tabla normalizada es minimizar el
número de celdas vacías.
6
Base de Datos 2009
El concepto relacional, significa que grupos parecidos de información son
almacenados en distintas tablas que luego pueden ser quot;juntadasquot;
(relacionadas) basándose en los datos que tengan en común.
Es necesario que al realizar la estructura de una base de datos, esta sea
flexible. La flexibilidad está en el hecho que podemos agregar datos al sistema
posteriormente sin tener que rescribir lo que ya tenemos.
La eficiencia se refiere al hecho de que no tenemos duplicación de datos, y
tampoco tenemos grandes cantidades de quot;celdas vacíasquot;.
Podríamos decir que estos son los principales objetivos de la normalización:
Controlar la redundancia de la información.
Evitar pérdidas de información.
Capacidad para representar toda la información.
Mantener la consistencia de los datos.
7.2. Seleccionar el Tipo de Dato Adecuado
Una vez identificadas todas las tablas y columnas que necesita la base de
datos, debemos determinar el tipo de dato de cada campo.
Existen tres categorías principales que pueden aplicarse prácticamente a
cualquier aplicación de bases de datos:
Texto
Números
Fecha y hora
Cada uno de éstos presenta sus propias variantes, por lo que la elección del
tipo de dato correcto no sólo influye en el tipo de información que se puede
almacenar en cada campo, sino que afecta al rendimiento global de la base de
datos.
A continuación se dan algunos consejos que nos ayudarán a elegir un tipo de
dato adecuado para nuestras tablas:
Identificar si una columna debe ser de tipo texto, numérico o de
fecha.
Elegir el subtipo más apropiado para cada columna.
Configurar la longitud máxima para las columnas de texto y numéricas,
así como otros atributos.
7.3. Utilizar Índices Apropiadamente
Los índices son un sistema especial que utilizan las bases de datos para
mejorar su rendimiento global. Dado que los índices hacen que las consultas se
ejecuten más rápido, podemos estar incitados a indexar todas las columnas de
nuestras tablas.
Sin embargo, lo que tenemos que saber es que el usar índices tiene un precio.
Cada vez que hacemos un INSERT, UPDATE, REPLACE, o DELETE sobre una
tabla, SQL tiene que actualizar cualquier índice en la tabla para reflejar los
cambios en los datos.
7
Base de Datos 2009
De manera simple, depende que tipo de consultas ejecutamos y que tan
frecuentemente lo hacemos, aunque realmente depende de muchas otras
cosas.
7.4. Usar Consultas REPLACE
Existen ocasiones en las que deseamos insertar un registro a menos de que
éste ya se encuentre en la tabla. Si el registro ya existe, lo que quisiéramos
hacer es una actualización de los datos.
7.5. Usar Una Versión Reciente de SQL
La recomendación es simple y concreta, siempre que esté en nuestras manos,
debemos usar la versión más reciente de SQL que se encuentre disponible.
Además de que las nuevas versiones frecuentemente incluyen muchas
mejoras, cada vez son más estables y más rápidas. De esta manera, a la vez
que sacamos provecho de las nuevas características incorporadas en SQL,
veremos significativos incrementos en la eficiencia de nuestro servidor de
bases de datos.
7.6. Usar Tablas Temporales.
Cuando estamos trabajando con tablas muy grandes, suele suceder que
ocasionalmente necesitemos ejecutar algunas consultas sobre un pequeño
subconjunto de una gran cantidad de datos. En vez de ejecutar estas consultas
sobre la tabla completa y hacer que SQL encuentre cada vez los pocos registros
que necesitamos, puede ser mucho más rápido seleccionar dichos registros en
una tabla temporal y entonces ejecutar nuestras consultas sobre esta tabla.
Una tabla temporal existe mientras dure la conexión a SQL. Cuando se
interrumpe la conexión SQL remueve automáticamente la tabla y libera el
espacio que ésta usaba.
8
Base de Datos 2009
Normalización
Normalizar es reconocer cualidades no deseadas en una tabla y la forma de corregirla.
Características:
Cualidades no deseadas
Evitar redundancia de información pero sin perderla
Existen dos formas para normalizar:
1. Enfoque intuitivo
2. Metodología.- Dependencia funcional
Dependencia Funcional
La dependencia funcional se da cuando hay tablas
El atributo A es funcionalmente dependiente del atributo B, si el valor de A está
determinado por el valor de B.
Para la tabla Ciudades, que tenia 2 campos, hemos creado el DIAGRAMA DE DEPENDENCIAS
FUNCIONALES
Valor de Columna de Tabla Valor de Columna de Tabla
CIUDAD (DETERMINA PK) CIUDAD
Id_ciudad_edit nombre_ciudad_edit
B A
Para la tabla Editoriales, que tenia 4 campos, hemos creado el DIAGRAMA DE
DEPENDENCIAS FUNCIONALES
Valor de Columna de Valor de Columna de Valor de Valor de
Tabla EDITORIAL Tabla EDITORIAL Columna Columna de
(DETERMINA PK) de Tabla Tabla
EDITORIAL EDITORIAL
Id_edit nombre_edit, direc_edit, id_ciudad_edit
B A,B,C
Tabla: Ciudades
id_ciudad_edit ( PK) nombre_ciudad_edit
02 Cuenca
04 Guayaquil
07 Quito
9
Base de Datos 2009
MODELO CORREGIDO Y NORMALIZADO
LIBRO EDITORIAL CIUDAD_EDIT
*debe asignarse
* debe publicar
Debe ser creado debe tener asignada
id_libro PK id_edit PK id_ciudad_edit PK
titulo nombre_edit nombre_ciudad_edit
edicion direc_edit
MODELO NO NORMALIZADO EN UNA UNICA Tabla: LIBROS
tipo_libro id_ciudad_edit FK
id_libro Titulo Edicion tipo_libro id_edit nombre_edit
id_edit FK
Direc_edit id_ciud_edit nomb_ciud_edit
PK NN NN NN
001 A Primera Ciencia F 101 LNS M. Aux 02 Cuenca
002 B Segunda Terror 102 Don Bosco Xxx 04 Guayaquil
003 C Primera Drama 103 Norma Yyy 07 Quito
004 Nacho Quinta Enseñanza 101 LNS M. Aux 02 Cuenca
Lee 1
005 Nacho Segunda Enseñanza 101 LNS M. Aux 02 Cuenca
Lee 2
09 Ambato
Se debe realizar un diagrama de Dependencias Funcionales (LO PRIMERO ES QUE DEBO
HACER ES VERIFICAR QUE “CAMPOS SERIAN DETERMINANTES, SERIA PK”
id_libro titulo, edicion, tipo_libro, id_edit, nombre_edit, direc_edit, id_ciud_edit,
nomb_ciud_edit
LUEGO INICIO EL Proceso de Normalización:
1FN 2FN 3FN 4FN
Problemas o Anomalías Dependencia Multivalorada(DMV)
- Inserción
- Actualización
- Eliminación
Solución para el Proceso de Normalización:
Atributos Clave (PK)
Atributos NO Clave (normales y los FK)
Crear nuevas tablas y que sus columnas no clave dependan total y funcionalmente únicamente
de su clave primaria.
(1FN ) Primera Forma Normal
Está en primera forma normal cuando los valores para los campos o columnas, en un
registro o fila de una tabla, TIENEN UN SOLO VALOR.
10
Base de Datos 2009
Ejm:
Tabla: LIBROS se encuentra en 1FN
id_libro titulo edicion tipo_libro id_edit nombre_edit Direc_edit id_ciud_edit nomb_ciud_edit
001 A Primera Ciencia F 101 LNS zzz 02 Quito
002 B Segunda Terror 102 Don Bosco xxx 04 Guayaquil
003 C Primera Drama 103 Norma yyy 07 Cuenca
Anomalías de inserción en 1FN.
Algunas anomalías de inserción se deben a la dependencia funcional de algunos campos no
clave en un subconjunto de atributos de la clave principal en lugar de toda la clave primaria.
Anomalías en la eliminación en 1FN.
Esto sucede cuando se desea borrar el valor de un campo, y al hacer esto no se puede borrar
sólo ese valor sino que se debe borrar todo el registro, y es donde aparece esta anomalía
debido a que se puede borrar información importante de una relación.
Anomalías de actualización en 1FN.
Cuando una relación sin normalizar se convierte en una relación 1FN, algunos datos se
duplican. Tal duplicidad de datos almacenados causará problemas en las operaciones de
actualización Y ADEMAS GENERARÁ INCONSISTENCIAS O ERRORES EN LOS DATOS.
(2FN )Segunda Forma Normal
Si esta en primera forma normal y cada atributo no clave depende totalmente de su clave
principal.
Ejm:
Anomalías de relaciones en 2FN
Puede presentar anomalías de almacenamiento si cualquiera de sus atributos no clave
depende transitivamente de la clave primaria, es decir depende indirectamente de la clave
primaria.
Ejm:
Tabla: LIBROS, esta en 1FN, está en 2 FN
id_libro titulo edicion tipo_libro id_edit
001 A Primera Ciencia F 101
002 B Segunda Terror 102
003 C Primera Drama 103
Tabla: EDITORIALES, esta en 1FN, está en 2FN
id_edit nombre_edit Direc_edit id_ciud_edit nomb_ciud_edit
PK
101 LNS zzz 02 Quito
102 Don Bosco xxx 04 Guayaquil
103 Norma yyy 07 Cuenca
Id_edit ----> nombre_edit, Direc_edit, id_ciud_edit, nomb_ciud_edit
11
Base de Datos 2009
(3FN) Tercera Forma Normal
Una relación es tercera forma normal si es 2FN y un atributo no clave YA NO ES
funcionalmente dependiente de algún otro atributo no clave.
Ejm:
Tabla: LIBROS, esta en 1FN, 2FN y 3FN
id_libro titulo Id_edicion_libro ID_tipo_libro id_edit
`PK FK FK FK
001 A 001 001 101
002 B 002 002 102
003 C 003 003 103
Tabla: TIPO_LIBROS, esta en 1FN, 2FN y 3FN
id_TIPO_libro tipo_libro
PK
001 Ciencia F
002 Terror
003 Drama
Tabla: EDICION_LIBROS, esta en 1FN, 2FN y 3FN
id_edicion_libro edicion
PK
001 Primera
002 Segunda
003 Primera
Tabla: EDITORIALES, está en 1FN, 2FN y 3FN
id_edit nombre_edit Direc_edit id_ciud_edit
PK FK
101 LNS zzz 02
102 Don Bosco xxx 04
103 Norma yyy 07
Tabla: CIUDADES, está en 1FN, 2FN y 3FN
id_ciud_edit nomb_ciud_edit
PK
02 Quito
04 Guayaquil
07 Cuenca
12
Base de Datos 2009
Anomalías debidas a dependencia de valores múltiples.
Generalmente un proceso de normalización termina cuando todas las relaciones pertenecen
a tercera forma normal. Sin embargo, si una relación contiene dependencias de valores
múltiples, es necesaria una normalización posterior. Dada una relación, el atributo A de esta
relación se dice ser dependiente de multivaluados (DMV) del atributo B si un rango específico
de valores del atributo A está determinado por un valor particular de B.
(4FN) Cuarta Forma Normal
Una relación es 4FN si es 3FN y no contiene dependencias multivaloradas.
La dependencia multivaluada se denota X Y, y se lee X multidetermina a Y.
13
Base de Datos 2009
Conclusiones.
La normalización es una técnica que se utiliza para crear relaciones lógicas apropiadas
entre tablas de una base de datos.
Ayuda a prevenir errores lógicos en la manipulación de datos. La normalización facilita
también agregar nuevas columnas sin romper el esquema actual ni las relaciones.
Normalizar demasiado puede conducir a tener una base de datos ineficiente y hacer a su
esquema demasiado complejo para trabajar.
La finalidad de este trabajo, es dar una inducción en el tema de Diseño de Bases de Datos, a
personas ajenas al tema. De manera que por ello los temas se presentan de una manera
sencilla y sin tanta terminología.
Nos muestra la gran importancia que para cualquier entidad, ya sea una empresa grande o
chica, para el gobierno, hasta para la vida cotidiana de una persona, tienen las bases de datos.
Todo gira alrededor de ellas, todos los procesos del mundo están registrados en ellas, de ahí la
importancia de llevar a cabo un diseño eficiente y libre de errores de las mismas.
Siempre que una persona escucha hablar de bases de datos y de toda la terminología que las
acompaña piensa que es un tema excesivamente complicado, y no es así, todo tiene un porqué
y lógica, es cosa de familiarizarse un poco con ellas (bases de datos).
Cuando se ven en realidad todas las ventajas que tienen, es más sencillo el proceso de
aprendizaje, ya que siente que el aprender a manejarlas se verá recompensado.
Además de los sencillas que son, es muy fácil acceder a información, manuales y cursos
relacionados a ellas, todo está a la mano, con la facilidad de poner este tema en un buscador
de la red y aparecerán infinidad de temas, unos más complejos que otros, pero siempre uno
que se adecue a las capacidades de aprendizaje de cada persona.
Recomendaciones.
El último paso del diseño de la base de datos es adoptar determinadas convenciones de
nombres. Aunque SQL es muy flexible en cuanto a la forma de asignar nombre a las bases de
datos, tablas y columnas, he aquí algunas reglas que es conveniente observar:
Utilizar caracteres alfanuméricos.
Limitar los nombres a menos de 64 caracteres (es una restricción de SQL).
Utilizar el guión bajo (_) para separar palabras.
Utilizar palabras en minúsculas (esto es más una preferencia personal que una regla).
Los nombres de las tablas deberían ir en plural y los nombres de las columnas en singular
(es igual una preferencia personal).
Utilizar las letras ID en las columnas de clave primaria y foránea.
En una tabla, colocar primero la clave primaria seguida de las claves foráneas.
Los nombres de los campos deben ser descriptivos de su contenido.
Los nombres de los campos deben ser unívocos entre tablas, excepción hecha de las claves.
14
Base de Datos 2009
Glosario
a) Base de Datos.- Cualquier conjunto de datos organizados para su almacenamiento en la
memoria de un ordenador o computadora, diseñado para facilitar su mantenimiento y
acceso de una forma estándar. Los datos suelen aparecer en forma de texto, números o
gráficos. Hay cuatro modelos principales de bases de datos: el modelo jerárquico, el
modelo en red, el modelo relacional (el más extendido hoy en día).
b) Base de Datos Relacional.- Tipo de base de datos o sistema de administración de bases
de datos, que almacena información en tablas (filas y columnas de datos) y realiza
búsquedas utilizando los datos de columnas especificadas de una tabla para encontrar
datos adicionales en otra tabla.
c) Datos Elementales.- Un dato elemental, tal como indica su nombre, es una pieza
elemental de información. El primer paso en el diseño de una base de datos debe ser un
análisis detallado y exhaustivo de los datos elementales requeridos.
d) Campos y Subcampos.- Los datos elementales pueden ser almacenados en campos o en
subcampos. Un campo es identificado por un rótulo numérico que se define en la FDT de
la base de datos. A diferencia de los campos, los subcampos no se identifican por medio
de un rótulo, sino por un delimitador de subcampo.
e) Delimitador de Subcampo.- Un delimitador de subcampo es un código de dos caracteres
que precede e identifica un subcampo de longitud variable dentro de un campo.
f) DBMS: Data Base Management System (SISTEMA DE MANEJO DE BASE DE DATOS).-
Consiste de una base de datos y un conjunto de aplicaciones (programas) para tener
acceso a ellos.
g) Modelo de Datos.- es un conjunto de herramientas conceptuales para describir los
datos, las relaciones entre ellos, su semántica y sus limitantes.
Errores que se pueden encontrar en el diseño de una base de datos:
h) Redundancia.- Esta se presenta cuando se repiten innecesariamente datos en los
archivos que conforman la base de datos.
i) Inconsistencia.- Ocurre cuando existe información contradictoria o incongruente en la
base de datos.
j) Dificultad en el Acceso a los Datos.- Debido a que los sistemas de procesamiento de
archivos generalmente se conforman en distintos tiempos o épocas y ocasionalmente
por distintos programadores, el formato de la información no es uniforme y se requiere
de establecer métodos de enlace y conversión para combinar datos contenidos en
distintos archivos.
k) Aislamiento de los Datos.- Se refiere a la dificultad de extender las aplicaciones que
permitan controlar a la base de datos, como pueden ser, nuevos reportes, utilerías y
demás debido a la diferencia de formatos en los archivos almacenados.
l) Anomalías en el Acceso Concurrente.- Ocurre cuando el sistema es multiusuario y no se
establecen los controles adecuados para sincronizar los procesos que afectan a la base
de datos. Comúnmente se refiere a la poca o nula efectividad de los procedimientos de
bloqueo.
m) Problemas de Seguridad.- Se presentan cuando no es posible establecer claves de
acceso y resguardo en forma uniforme para todo el sistema, facilitando así el acceso a
intrusos.
n) Problemas de Integridad.- Ocurre cuando no existe a través de todo el sistema
procedimientos uniformes de validación para los datos.
15
Base de Datos 2009
Niveles de Diseño:
a) Nivel Físico.- Es aquel en el que se determinan las características de almacenamiento
en el medio secundario. Los diseñadores de este nivel poseen un amplio dominio de
cuestiones técnicas y de manejo de hardware.
b) Nivel Conceptual.- Es aquel en el que se definen las estructuras lógicas de
almacenamiento y las relaciones que se darán entre ellas. Ejemplos comunes de este
nivel son el diseño de los registros y las ligas que permitirán la conexión entre registros
de un mismo archivo, de archivos distintos incluso, de ligas hacia archivos.
c) Nivel de Edición.- Es aquel en el que se presenta al usuario final y que puede tener
combinaciones o relaciones entre los datos que conforman a la base de datos global.
Puede definirse como la forma en el que el usuario aprecia la información y sus
relaciones.
Clasificación de Modelos de Datos:
a) Modelos Lógicos Basados en Objetos.- Son aquellos que nos permiten una definición
clara y concisa de los esquemas conceptuales y de visión. Su característica principal es
que permiten definir en forma detallada las limitantes de los datos.
b) Modelos Lógicos Basados en Registros.- Operan sobre niveles conceptual y de visión.
Sus características principales son que permiten una descripción más amplia de la
implantación, pero no son capaces de especificar con claridad las limitantes de los datos.
c) Modelos Físicos de Datos.- Describen los datos en el nivel más bajo y permiten
identificar algunos detalles de implantación para el manejo del hardware de
almacenamiento.
16