Temas:
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 2
1.1 Definición
Relación:
Dados los conjuntos D1, D2,..., Dn (no necesariamente distintos), R es una
relación sobre esos n conjuntos, si está constituida por un conjunto de n-tuplos
ordenados d1, d2,...dn tales que, d1
D1, d2 D2,..., dn
Dn.
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 3
COLUMNAS
. . . (Atributos)
. . .
FILAS
. . . (Ocurrencias)
Cada relación está compuesta de filas (las ocurrencias de los objetos) y se les
denomina, como tuplos, tuplas, uplos o uplas (en realidad, n-tuplos, pero en
muchos casos se suprime la n cuando no existe posibilidad de confusión).
También, la relación está compuesta por columnas (los atributos o campos que
toman valores en sus respectivos dominios).
Ejemplo:
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 4
SUMINISTRADOR SP
P1 CLAVO 0.10 12
P2 TUERCA 0.15 17
P3 MARTILO 3.50 80
P4 TORNILLO 0.20 10
P5 ALICATE 2.00 50
P6 SERRUCHO 4.00 90
Asimismo, las diversas formas de expresar las recuperaciones dan lugar a los
lenguajes relacionales cuyas formas más representativas son:
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 5
Relaciones:
Generalmente, se denomina tabla (aunque existe una diferencia
para el modelo relacional entre tabla y relación).
Cada tabla es una entidad diferente.
Las tablas almacenadas en la base de datos se denominan Tablas
bases.
Las que se crean a partir de ellas, se denominan Tablas virtuales
(Memoria).
Cada relación posee un nombre que está asociado con los datos
que almacena.
Cada relación está formada, a su vez, por Atributos y Tuplas.
Atributos:
Es un elemento de datos que describe a la entidad representada por
medio de la tabla, que, en su implementación, conforma lo que sería
una columna (campo) de dicha tabla. Cada atributo posee un nombre
que, normalmente, sugiere el tipo de datos que se almacenará en dicho
atributo.
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 6
Tuplas:
Se denomina así a cada fila de la relación (tabla). Cada tupla refleja
una ocurrencia de la relación.
Dominio:
Es el conjunto de valores permitidos para un atributo, validado por
reglas convencionales o del negocio.
Su implementación en una base de datos, libera a la misma de los
famosos “errores” de los usuarios.
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 7
- Restringida.
- De cascada.
- Anulación.
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 8
Adicionar registros.
Actualizar registros.
Eliminar registros.
- Lógicamente.
- Físicamente.
Consultar registros.
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 9
2.1 Introducción
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 10
Numérico exacto
Numérico aproximado
Fecha y hora
Cadena de carácter
Carácter unicode
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 11
Cadenas binarias
Nota: los tipos de datos TEXT y NTEXT e IMAGE ya no deben ser utilizados, solo se
mantienen para compatibilidad con versiones anteriores. La equivalencia de uso es la
siguiente:
A continuación, se indicará como definir los tipos de datos para el modelo físico
elaborado con ER/One Data Modeler.
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 12
En este punto, con la ayuda del SQL Server Managment Studio, crear una base de datos
llamada AEREOLINEA, para el ejemplo.
Para crear los objetos de la base de datos, ER/One Data Modeler crea un procedimiento
que contiene todas las sentencias SQL que deben ejecutarse para crear los objetos
definidos en el modelo físico. Por ello, se puede:
1. En el menú Tools, ejecutar la opción Generate DLL Script o dar clic en el siguiente
ícono .
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 13
Para crear un script SQL que puede ser editado y ejecutado, posteriormente
1. En el menú Tools, ejecutar la opción Generate DLL Script o dar clic en el siguiente
ícono .
3. Dar clic en la opción Save to File y especificar la ubicación y el nombre del archivo
que almacenará el script (guardarlo con extensión sql). Por ejemplo,
ObjetosAereolinea.sql
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 14
2. Hacer clic sobre la base de datos AEREOLINEA utilizando el botón secundario del
ratón.
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 15
3. Normalización de datos
3.1. Definición
El concepto de normalización fue introducido por E.D. Codd y fue pensado para
aplicarse a sistemas relacionales; sin embargo, tiene aplicaciones más amplias.
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 16
Primera forma normal (1FN): establece que las columnas repetidas deben
eliminarse y colocarse en tablas separadas. Las celdas de la tabla deben
poseer valores simples y no se permiten grupos ni arreglos repetidos como
valores. Todos los ingresos en cualquier columna (atributo) deben ser del
mismo tipo. Asimismo, cada columna debe tener un nombre único, el orden de
las columnas en la tabla no es importante. Dos hileras en una tabla no deben
ser idénticas, aunque el orden de las hileras no es importante.
Segunda forma normal (2FN): para que una tabla esté en 2NF tiene que
cumplir con lo siguiente:
Estar en 1FN.
Todas las dependencias parciales se deben eliminar y separar dentro de
sus propias tablas. (Una dependencia parcial es un término que describe a
aquellos datos que no dependen de la llave primaria de la tabla para
identificarlos).
La 2FN solo se aplica para llaves compuestas.
La tercera forma normal (3FN): señala que hay que eliminar y separar
cualquier dato que no sea clave. El valor de esta columna debe depender de la
llave. Todos los valores deben identificarse únicamente por la llave. Del mismo
modo, elimina cualquier dependencia transitiva (aquella en la cual, las
columnas que no son llave son dependientes de otras columnas que tampoco
lo son).
Ejemplo de aplicación:
Variable Murray
1001 McGraw Hill Pérez Gómez, Juan 15/04/2005
compleja Spiegel
Visual Basic E.
1004 Anaya Ríos Terán, Ana 17/04/2005
2005 Petroustsos
Murray
1005 Estadística McGraw Hill Roca, René 16/04/2005
Spiegel
Autor1:
Nancy
Oracle
1006 Greenberg Oracle Corp. García Roque, Luis 20/04/2005
University
Autor 2:
Priya Nathan
Power Builder
1007 Ramalho McGraw Hill Pérez Gómez, Juan 18/04/2005
10.0
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 17
Esta tabla no cumple el requisito de la primera forma normal (1NF) de solo tener
campos atómicos, pues el nombre del lector es un campo que puede (y conviene)
descomponerse en apellido paterno, apellido materno y nombres. Tal como se
muestra en la siguiente tabla.
1NF
Variable McGraw
1001 Murray Spiegel Pérez Gómez Juan 15/04/2005
compleja Hill
Visual
1004 E. Petroustsos Anaya Ríos Terán Ana 17/04/2005
Basic 2005
McGraw
1005 Estadística Murray Spiegel Roca René 16/04/2005
Hill
Oracle Oracle
1006 Priya Nathan García Roque Luis 20/04/2005
University Corp.
Power McGraw
1007 Ramalho Pérez Gómez Juan 18/04/2005
Buider 10.0 Hill
Por ejemplo, el título es completamente identificado por el código del libro, pero el
nombre del lector en realidad no tiene dependencia de este código, por tanto,
estos datos deben ser trasladados a otra tabla.
2NF
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 18
Se ha creado una tabla para contener los datos del lector y también se creó la
columna CodLector para identificar unívocamente a cada uno. Sin embargo, esta
nueva disposición de la base de datos necesita que exista otra tabla para
mantener la información de qué libros están prestados y a qué lectores.
Para la tercera forma normal (3NF) la relación debe estar en 2NF y además, los
atributos no clave, deben ser mutuamente independientes y dependientes por
completo, de la clave primaria. Esto significa que las columnas en la tabla deben
contener solamente información sobre la entidad definida por la clave primaria y,
por tanto, las columnas en la tabla deben contener datos acerca de una sola cosa.
En el ejemplo en 2NF, la primera tabla conserva información acerca del libro, los
autores y editoriales, por lo cual, se deberán crear nuevas tablas para satisfacer
los requisitos de 3NF.
3NF
CodLibro Titulo
1001 Variable compleja
1004 Visual Basic 2005
1005 Estadística
1006 Oracle University
1007 Power Builder 10.0
CodAutor Autor
801 Murray Spiegel
802 E. Petroustsos
803 Nancy Greenberg
804 Priya Nathan
806 Ramalho
CodEditorial Editorial
901 McGraw Hill
902 Anaya
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 19
CodEditorial Editorial
903 Oracle Corp.
Aunque se han creado nuevas tablas para que cada una tenga información acerca
de una entidad, también se ha perdido la información acerca de qué autor ha
escrito qué libro y las editoriales correspondientes, por ende, se deberán crear
otras tablas que relacionen cada libro con sus autores y editoriales.
CodLibro codAutor
1001 801
1004 802
1005 801
1006 803
1006 804
1007 806
CodLibro codEditorial
1001 901
1004 902
1005 901
1006 903
1007 901
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016
Modelo físico relacional de base de datos 20
El normalizar una base de datos, depende de la aplicación que se desarrolle. Si el diseño solo tiene una
clase persistente, generalmente, se debería tener una tabla representándola.
Uno de los principales mitos respecto a las consecuencias de normalizar una BBDD es pensar que en un
motor relacional es costoso procesar un join.
Esto incide en el hecho de tener tres tablas (resultado de una normalización) y luego, realizar una consulta
sobre las tres tablas, entonces se tendrán que hacer 2 joins.
El tiempo de respuesta es menor si solo se consulta una tabla. En una aplicación pequeña esto pasa
desapercibido, pero en una aplicación que maneja grandes volúmenes de acceso a datos, de seguro que si
se toma en cuenta. Sin embargo, las consultas a una BBDD son solo una pequeña parte de lo que una
aplicación hace con ellas.
Por otro lado, si se quiere eliminar un registro en una tabla, y esa tabla está relacionada con otras, se
tendrá que eliminar también el registro de esas tablas.
Cibertec Perú S.A.C – SQL y modelamiento de base de datos - SQL Server 2016