Instructivo de Diseño de Bases de Datos y Normalización

Materia: Tecnología de la Información
Profesor: Ariana Rosenthal
Cátedra: Silvia Koklia
FCE – UBA
Tema: “Planeación y Modelado de Datos”
Autores:
Alejandro Markovic
Lic Ana Paula Vidal
Lic Ariana Rosenthal
F.C.E. – Universidad de Buenos Aires
Cátedra Lic. Silvia Koklia
Tecnología de la información
Prof. Lic. Ariana Rosenthal
Instructivo Diseño de bases de datos y
Normalización
Una base de datos es una colección ordenada de datos cuyo fin es ser utilizado
para diversas aplicaciones. Existen 3 tipos básicos de bases de datos:
Jerárquica Æ estructura ordenada en función a un orden de
jerarquías, como si fuera un organigrama. Su desventaja radica en
que no permite una relación de mucho a muchos.
Red Æ permite relaciones de muchos a muchos, pero son poco
eficientes y difícilmente administrables, sobre todo si se trata de
grandes bases de datos.
Relacional Æ se componen de tablas bidimensionales con campos y
registros, y la relación entre tablas se establece entre el contenido en
ellas (campos comunes).
En las clases de Tecnología de la Información, utilizaremos las bases de
datos relacionales.
BASES DE DATOS RELACIONALES
Elementos principales
Entidad Æ es un objeto de la realidad que posee características
(“atributos”). Físicamente se llama “tabla” a una entidad. Los
atributos de una entidad pueden tener distintos tipos de datos:
numéricos, alfanuméricos, fecha, moneda, etc. Los atributos de
una entidad, deberán tener coherencia entre ellos.
Cuando a los atributos de una entidad se les asigna un valor,
estamos frente a una ocurrencia (se completa el registro o fila).
Ejemplo: modelar los datos de un alumno de la Universidad.
ALUMNO
Nº de registro
Apellido
Nombre
Domicilio
Clave primaria Æ es el campo (columna) ó conjunto de campos
que permiten identificar unívocamente a un registro (fila). En el
diseño de una base de datos, es el/los atributo/s por el/los cual/es
podemos identificar a cada uno de los registros. La manera de
indicarlos en el diseño es subrayándolo/s.
Por lo general, la clave primaria es un dato numérico, con el fin de
servir más eficientemente a la identificación de un registro.
1
F.C.E. – Universidad de Buenos Aires
Cátedra Lic. Silvia Koklia
Tecnología de la información
Prof. Lic. Ariana Rosenthal
ALUMNO
Nº de registro
Apellido
Nombre
Domicilio
Clave primaria (con ella puedo identificar a cada alumno y sus
datos, dentro de la base de datos)
La clave primaria puede ser simple o compuesta.
Clave primaria compuesta o combinada o concatenada
Æ se necesitan de dos campos o más para identificar un
registro, dada la repetición de datos en distintos registros.
Ejemplo: Modelar los datos de un empleado que trabaja en
más de una empresa.
EMPLEADO_EMPRESA
CUIL
Cod. Empresa
Nombre
Nº Legajo
Domicilio part.
Clave foránea Æ campo utilizado para relacionar una tabla con otra
(se trata de uno o varios campos que son clave en una tabla A y que
para permitir la relación se agregan en la tabla B, sean o no claves en
la tabla B).
Celda Æ es una ocurrencia. Se trata de un campo con datos para
un registro determinado.
Relación Æ es la unión que existe entre dos entidades, que
seguramente esté dada por algún campo común entre ellas (a la hora
de diseñar una base de datos relacional, la relación entre dos o más
entidades estará dada porque la clave primaria completa de la tabla A
se encuentra en la tabla B, sin necesidad de ser clave en la tabla B).
2
F.C.E. – Universidad de Buenos Aires
Cátedra Lic. Silvia Koklia
EMPLEADO
CUIL
Nombre
Apellido
Domicilio part.
Tecnología de la información
Prof. Lic. Ariana Rosenthal
EMPLEADO_EMPRESA
CUIL
Cod. Empresa
Nº Legajo
Interno
EMPRESA
Cod. Empresa
Razón Social
Domicilio
Localidad
Teléfono
Normalización
Es un conjunto de reglas o “formas normales” que permite armar un diseño de
base de datos en forma más óptima (facilitar la actualización de los datos, ahorrar
espacio en el almacenamiento de ellos, facilitar el acceso y utilización de los datos
almacenados).
Las 3 formas normales, acumulativas, que utilizaremos a lo largo del curso son las
siguientes:
1º FORMA NORMAL
No debe haber grupos repetitivos en las entidades (cuando una
ocurrencia puede tomar más de un valor en un mismo atributo).
Ejemplo:
ALUMNO
Nº de registro
Apellido
Nombre
Teléfono
GRUPO REPETITIVO!!!
Si un alumno tiene más de un teléfono, este a
atributo podrá tomar más de un valor
SOLUCIÓN
ALUMNO
Nº de registro
Apellido
Nombre
Teléfono
TEL_ALUMNO
Nº de registro
Teléfono
Para solucionar un caso de grupo repetitivo, se saca el atributo repetitivo
de su entidad original y se genera una nueva entidad que tendrá una
clave primaria compuesta: la clave primaria de la entidad originaria más el
atributo repetitivo, ahora también como clave.
3
F.C.E. – Universidad de Buenos Aires
Cátedra Lic. Silvia Koklia
Tecnología de la información
Prof. Lic. Ariana Rosenthal
Tener en cuenta que si se decidiera registrar un único valor para el atributo Teléfono, no
habría grupo repetitivo y no sería necesaria la solución descripta.
Toda entidad debe tener clave primaria (ya sea simple o compuesta)
Los datos incluidos en las entidades deben ser atómicos (no pueden
abrirse en más de un “subdato” que nos interese consultar).
Ejemplo:
DOMICILIO
Según las necesidades del usuario, este dato
podría no ser atómico, porque puede abrirse en
más de un “subdato”:
• Calle
• Nro.
• Código postal
• Localidad
• Provincia
2º FORMA NORMAL
Debe cumplirse con la 1º forma normal
Debe existir dependencia funcional entre los atributos de una entidad:
todo dato no clave debe depender de la totalidad de la clave.
Ejemplo:
ALUMNO
Nº de registro
Teléfono
Apellido
Nombre
Los atributos “Nombre” y “Apellido”
dependen del número de registro (parte de
la clave de esta entidad) pero no del
teléfono del alumno.
3º FORMA NORMAL
Debe cumplirse con la 2º forma normal
No debe haber dependencia funcional transitiva: todo dato que no es
clave no puede depender de otro que tampoco lo sea.
4
F.C.E. – Universidad de Buenos Aires
Cátedra Lic. Silvia Koklia
Tecnología de la información
Prof. Lic. Ariana Rosenthal
Ejemplo:
ALUMNO
Nº de registro
Apellido
Nombre
Cod_Materia
Profesor
Suponiendo que el alumno puede hacer
sólo una materia, el atributo “Profesor”
dependería del atributo “Materia”, dado
que el profesor varía en función de la
materia y no del alumno.
Pasos a seguir a la hora de resolver un ejercicio de diseño de base de
datos
1º) Identificar los atributos que corresponden según el enunciado
2º) Identificar las entidades que engloban a los atributos listados en el paso
anterior.
3º) Ubicar los atributos en las entidades definidas
4º) Crear nuevas y necesarias entidades a fin de cumplir con las formas
normales
5º) Identificar los atributos que son claves primarias
6º) Establecer relaciones entre las entidades
7º) CONTROLAR EL CUMPLIMIENTO DE LAS FORMAS NORMALES
8º) Realizar el Diagrama Entidad Relación (DER), que reflejará
gráficamente lo diseñado en el modelado de datos. Se compone de dos
elementos:
√ Rectángulo Æ representa a cada entidad
√ Línea Æ representa las relaciones entre las entidades y la
cardinalidad en ellas.
Cardinalidad
Refleja la cantidad de ocurrencias que se comparten dentro de
cada relación:
• De uno a uno Æ
• De uno a mucho Æ
• De muchos a mucho Æ
5
F.C.E. – Universidad de Buenos Aires
Cátedra Lic. Silvia Koklia
Tecnología de la información
Prof. Lic. Ariana Rosenthal
Ejemplo:
Empleado
Empleado_Empresa
Esta relación de unos a muchos
indica que un “Empleado_Empresa”
se refiere siempre a un solo
“Empleado”; y un “Empleado” puede
trabajar en muchas empresas (en
cada una tendrá su número de legajo
y su interno, pero siempre referido a
un único CUIL).
Empresa
Esta relación de unos a muchos
indica que un “Empleado_Empresa”
se refiere siempre a una sola
“Empresa”; y un “Empresa” puede
repetirse dentro de todos los
empleados registrados.
CONSEJOS ÚTILES
NUNCA cardinalidad “muchos a muchos” Æ para solucionarlo se creará
una nueva entidad, que seguramente compartirá la clave de las entidades
originales: “entidad asociativa”
El Diagrama Entidad Relación debe reflejar el diseño de las entidades.
La cardinalidad “uno a uno” se da cuando dos entidades tienen la misma
clave.
Los datos que son predeterminados, limitados en su cantidad y
actualizables muy raramente es preferible preestablecerlos en el sistema,
dando origen a “entidades maestras”, que estarán compuestas, en general
por la clave primaria y por un campo “descripción”.
Los datos calculables no se reflejan como atributo en el modelado de
datos
6
F.C.E. – Universidad de Buenos Aires
Cátedra Lic. Silvia Koklia
Tecnología de la información
Prof. Lic. Ariana Rosenthal
Ejemplo:
LOCALIDAD
Cod. Localidad
Descripción
Cod. Localidad
Descripción
01
Capital Federal
02
Lanús
03
Avellaneda
04
Morón
05
Martínez
Prueba de escritorio
En este caso, se sabe de antemano que las empresas con las
cuales trabajaré estarán ubicadas en estas 5 localidades. Es por
eso que creo esta “entidad maestra” que facilitará la carga de
datos y el análisis de la información, codificando los datos que se
usarán.
7