DFo 3 4 SG Esp

Fundamentos de bases de datos
3-4
Asignación y terminología del modelado de datos
Copyright © 2019, Oracle y/o sus filiales. Todos los derechos reservados.
2
Guía básica Se encuentra aquí
Asignación y
Más sobre Seguimiento Normalización terminología
relaciones de cambios y reglas de del modelado
de datos negocio de datos
DFo 3-4
Asignación y tecnología del modelado de datos Copyright © 2019, Oracle y/o sus filiales. Todos los derechos reservados. 3
3
Objetivos
En esta lección se abordan los siguientes objetivos:
• Aplicar la asignación de terminología entre los modelos
lógicos y físicos
• Comprender y aplicar las convenciones de
nomenclatura de Oracle para tablas y columnas
utilizadas en los modelos físicos
• Aplicar las reglas de asignación de relaciones
para transformar las relaciones
correctamente
DFo 3-4
4
Transformación de lógico a físico: Ejemplo
Modelo EMPLOYEE DEPARTMENT
lógico (ERD) # id # id
* first name * name
* last name
Transformation
(#) payroll id
process
EMPLOYEES (EPE) Implementación física:

Key Type Optionality Column name Base de datos relacional
pk * id
uk * payroll_id DEPARTMENTS (DPT)
* last_name
Key Type Optionality Column name
pk * id
* first_name
fk * department_id * name
DFo 3-4
5
Asignación de terminología
ERD Diseño físico

Entity Tabla
Instance Fila
Atributo Columna Implantación

Análisis
UID primario Clave primaria
UID secundario Clave única
Relación Clave ajena
DFo 3-4
6
Entidad y tabla correspondiente
Entidad STUDENT
# id
* first name
* last name Tabla
Tabla STUDENTS
ID FIRST_NAME LAST_NAME
DFo 3-4
7
Atributos y columnas correspondientes
STUDENT
Atributo
# id
* first name
* last name
* street address
* city
Columna Tabla STUDENTS
ID FIRST_NAME LAST_NAME STREET_ADDRESS CITY
DFo 3-4
Los atributos se clasifican de una de las siguientes formas:

• No nulo (obligatorio): Indicado por el símbolo de asterisco (*) situado junto al atributo
• Opcional (se permiten valores nulos): Se indica con la o (opcional) junto al atributo
8
Una instancia y una fila correspondiente
Entidad Instance
STUDENT J Smith
ID FIRST_NAME LAST_NAME STREET_ADDRESS CITY

101 Sam Linkin 99B, Chuah Street LA
102 Neena Markin 44A, Church Street NZ
103 Rick Austina 1st Cross, Palm Street SA
104 J Smith Alpha Street CA Fila
DFo 3-4
9
Notaciones de diagrama de tabla
• Un diagrama de tabla es documentación adicional que
se suele utilizar para explicar con mayor detalle las
claves y columnas de la base de datos física.
Tabla STUDENTS
Key Type Optionality Column Name
pk * id
* first_name
* last_name
* street_address
* city
DFo 3-4
• La columna Tipo de clave debe contener valores de "pk" para la clave primaria, "uk" para la clave única o
"fk" para la columna de clave ajena. La celda está vacía si la columna no forma parte de una clave.
• La columna Optionality debe contener un asterisco (*) si la columna es obligatoria y una "o" en minúscula si
es opcional. Se parece al ERD.
• La tercera columna es para el nombre de columna.
10
Reglas de nomenclatura para tablas
• El nombre de la tabla es el STUDENT
plural del nombre de la # id
* first name
entidad. * last name
– Ejemplo: STUDENT * street address
* city
se convierte en STUDENTS.
• Los nombres de columna
STUDENTS
son idénticos a los nombres Key Type Optionality Column name
de atributo, excepto en que pk * id
los caracteres especiales y * first_name
espacios se sustituyen por * last_name
caracteres de subrayado. * street_address
* city
DFo 3-4
11
Reglas de nomenclatura para columnas
• Los nombres de columna se
STUDENT
parecen a los nombres de # id
atributo, excepto en que * first name
* last name
los caracteres especiales y * street address
espacios se sustituyen por * city
caracteres de subrayado.
• Los nombres de columna STUDENTS
suelen utilizar más Key Type Optionality Column name
abreviaturas que los pk * id
nombres de atributo. * first_name
– Ejemplo: First name se convierte * last_name
en first_name o fname. * street_address

* city
DFo 3-4
12
12
Nombres abreviados de la tabla
• Al asignar nombre a las
columnas de clave ajena es PRIVATE HOME
útil utilizar una abreviatura # id
única para todas las tablas. * address
o comments
PRIVATE_HOMES (PHE)
pk * id
* address
o comments
DFo 3-4
13
Nombres abreviados de la tabla
• Cree abreviaturas basadas
en: PRIVATE HOME
– Nombres de entidad que # id
contienen más de una * address
o comments
palabra
– Nombres de entidad que
contienen una palabra,
pero más de una sílaba PRIVATE_HOMES (PHE)
– Nombres de entidad que Key Type Optionality Column name
contienen una sílaba, pk * id
pero más de un carácter * address
o comments
DFo 3-4
Para los nombres de entidad que contienen más de una palabra, utilice:
• El primer carácter de la primera palabra
• El primer carácter de la segunda palabra
• El último carácter de la última palabra
Ejemplo: PRIVATE HOME se convierte en la abreviatura PHE.
Para los nombres de entidad que contienen una palabra, pero más de una sílaba, utilice:
• El primer carácter de la primera sílaba
• El primer carácter de la segunda sílaba
• El último carácter de la última sílaba
Ejemplo: EMPLOYEE se convierte en la abreviatura EPE y CLIENT en la abreviatura CET.
Para los nombres de entidad que contienen una sílaba, pero más de un carácter, utilice:
• El primer carácter
• El segundo carácter
• El último carácter
Ejemplo: FLIGHT se convierte en la abreviatura FLT.
14
Restricciones de nomenclatura con Oracle
• Nombres de tabla y de columna:
– Debe empezar por una letra
– Puede contener hasta 30 caracteres alfanuméricos
– No puede contener espacios ni caracteres especiales como "!";
pero "$", "#" y "_" están permitidos
– No puede haber "palabras reservadas" en Oracle DB o SQL
• Los nombres de tabla deben ser únicos en una cuenta
de usuario en la base de datos Oracle.
• Los nombres de columna deben ser únicos en una tabla.
DFo 3-4
15
Asignación de relaciones
• Las relaciones se asignan entre claves primarias y claves
ajenas para permitir que una tabla haga referencia a
otra.
• Una relación crea una o más columnas de clave ajena
en la tabla, en la parte de varios de la relación.
• Utilizamos la abreviatura de la tabla para asignar un
nombre a la columna de clave ajena.
• En el ejemplo de la siguiente página, la columna de
clave ajena de la tabla EMPLOYEES es dpt_id para la
relación con DEPARTMENT y mgr_id para la relación
recursiva consigo mismo.
DFo 3-4
16
Ilustración de la asignación de relaciones
managed by
the EMPLOYEE belong to DEPARTMENT

manager of # id # id
* first name composed of * name
* last name
* payroll id
EMPLOYEES (EPE)
DEPARTMENTS (DPT)
Key Optionality Column name
pk * id
Type
* first_name
pk * id
* last_name uk * name
uk * payroll_id
fk1 * dpt_id la clave ajena hace referencia a
fk2 o mgr_id
la clave ajena hace referencia a
DFo 3-4
17
Asignación de relaciones de bloqueo
• Una relación de bloqueo se asigna a una columna de
clave ajena en la parte de varios, igual que cualquier
otra relación 1:M.
• En este caso, la columna de clave ajena desempeña
un rol doble porque también forma parte de la
clave primaria.
• En el ejemplo, bak_number es una columna de clave
ajena en ACCOUNTS que hace referencia a la clave
primaria de BANKS.
• También forma parte de la clave primaria de
ACCOUNTS.
DFo 3-4
18
Asignación de relaciones de bloqueo
ACCOUNT located in BANK

# number # number
* balance * name
the location of
* date opened
ACCOUNTS (ACT)
BANKS (BAK)
Key Type Optionality Column
pk * number
name
* balance
pk * number
* date_opened * name
pk,fk * bak_nbr
la clave ajena hace referencia a
DFo 3-4
19
Asignación de relaciones de varios a varios
• Una relación M:M se resuelve con una entidad de
intersección, que se asigna a una tabla de intersección.
• Esta tabla de intersección contendrá columnas de clave
ajena que hacen referencia a las tablas de origen.
• En el ejemplo, REVIEWS contiene todas las
combinaciones que existen entre CRITIC y MOVIE.
DFo 3-4
20
Asignación de relaciones de varios a varios
REVIEW
* rating
CRITIC MOVIE
# id # id
* name * title
CRITICS (CTC)
REVIEWS (RVW) Key Type Optionality Column name

pk * id
* name
pk,fk1 * ctc_id
MOVIES (MVE)
pk,fk2 * mve_id
* rating
pk * id
* title
DFo 3-4
21
Asignación de relaciones de uno a uno
• Al transformar una relación 1:1, deberá crear una clave
ajena y una clave única.
• Todas las columnas de esta clave ajena también forman
parte de la clave única.
• Si la relación es obligatoria en una parte, se crea la
clave ajena en la tabla correspondiente.
• En el ejemplo, cbe_code es una columna de clave ajena
en EMPLOYEES que hace referencia a la clave primaria
de CUBICLES.
• Cbe_code también será único en la tabla EMPLOYEES.
DFo 3-4
22
Asignación de relaciones de uno a uno
EMPLOYEE allocated CUBICLE

# id # code
* first_name * description
allocated to
* last_name
EMPLOYEES (EPE) CUBICLES (CBE)
Key Type Optionality Column name Key Type Optionality Column

pk * id name
* first_name pk * code
* description
last_name
fk,uk * cbe_code
DFo 3-4
23
Asignación de arcos
• La entidad que tiene el arco se asignará a una tabla que
contenga las claves ajenas de las tablas en el extremo
"uno" de las relaciones.
• Tenga en cuenta que, aunque las relaciones del arco
sean obligatorias en la parte de varios, las claves ajenas
resultantes tienen que ser opcionales (ya que una de
ellas siempre estará en blanco). Una restricción de
control almacenada en la base de datos puede hacerlo
fácilmente.
DFo 3-4
24
Asignación de arcos COMPANY
# id
held by
* name
MEMBERSHIP * contact name
the holder of
# id
* start date CUSTOMER
* expiration date held by # id
o termination the holder of * first_name
* last_name
COMPANIES (CPE)
MEMBERSHIPS (MBP)
pk * id
pk * id * name
* start_date * contact_name
* expiration_date
o termination CUSTOMERS (CMS)
fk1 o cpe_id Key Type Optionality Column name

fk2 o cms_id pk * id
* first_name
* last_name
DFo 3-4
Puesto que el arco representa relaciones de bloqueo, se necesita código adicional para aplicar que solo una
de las claves ajenas tenga un valor para cada fila de la tabla.
Una restricción de control almacenada en la base de datos puede hacerlo fácilmente.
En el ejemplo, el código para la restricción de control tendrá un aspecto similar a este:
• CHECK (cpe_id is not null AND cms_id is null)
• OR (cpe_id is null AND cms_id is not null)
Si las relaciones fueran totalmente opcionales, tendría que agregar: OR (cpe_id is null AND cms_id is null)
25
Asignación de supertipo/subtipos
Las entidades de supertipo/subtipo se pueden asignar de
varias formas:
– Implantación de tabla única: se crea una tabla
independientemente del número de subtipos, se utiliza cuando
se comparte la mayoría de atributos y relaciones y, por lo
tanto, en el nivel de supertipo.
– Implantación de dos tablas: se crea una tabla para cada subtipo
(por lo que puede haber más de dos tablas),
se utiliza cuando los subtipos tienen poco en común y
comparten algunos atributos y relaciones.
DFo 3-4
26
Implantación de tabla única
• La tabla única obtiene una columna para cada atributo
del supertipo, junto con la opcionalidad original del
atributo.
• La tabla también obtiene una columna para cada
atributo que pertenece al subtipo, pero todas las
columnas se convierten en opcionales.
• Además, se debe crear una columna obligatoria
para que actúe como columna discriminadora con
el fin de distinguir entre los diferentes subtipos de
la entidad.
DFo 3-4
27
Implantación de tabla única DEPARTMENTS (DPT)
pk * id
the manager of
AGENCIES (AGY)
EMPLOYEE
pk * id
# id
* first name managed by
EMPLOYEES (EPE)
* last name OTHER assigned to
DEPARTMENT Key Type Optionality Column name
# id
FULL TIME the home for pk * id
* salary
* first_name
PART TIME employed by
AGENCY * last_name
* hourly rate # id
the source of
o salary
o hourly_rate
fk1 * dpt_id
fk2 o agy_id
* epe_type
fk3 o mgr_id
DFo 3-4
Identificadores: Los identificadores únicos se transforman en claves primarias y únicas.

Relaciones: Las relaciones del nivel de supertipo se transforman de la forma habitual. Las relaciones en el
nivel de subtipo se implantan como columnas opcionales de clave ajena.
Restricciones de integridad: Se requiere una restricción de control para garantizar que para cada subtipo
concreto ninguna de las columnas que proceden de atributos obligatorios es nula.
En el modelo lógico, el salario es obligatorio para los empleados a tiempo completo y la tasa por hora es
obligatoria para los empleados a tiempo parcial.
•Cuando se implanta el supertipo EMPLOYEE como tabla única en el modelo físico, estos atributos se
convierten en opcionales.
•Se necesita una restricción de control para aplicar las reglas de negocio modeladas en el ERD.
28
Implantación de dos tablas
• Una tabla por subtipo de primer nivel.
• Cada tabla obtiene una columna para cada atributo del
supertipo junto con su opcionalidad original.
• Cada tabla también obtiene una columna para
cada atributo que pertenece al supertipo junto
con su opcionalidad original.
DFo 3-4
29
Implantación de dos tablas
CLOTHING
produced by
# id MANUFACTURER
* material # id
the producer of
SHIRT
* sleeve length altered by
* neck size TAILOR
o collar style the alterer of # id
SHOE
* size repaired by
* buckle style COBBLER
o heel height the repairer of # id
SHIRTS (SHT) SHOES (SHE)

Key Type Optionality Column name Key Type Optionality Column name
pk * id pk * id
* material * material
* sleeve_length * size
* neck_size * buckle_style
o collar_style o heel_height
fk1 o tlr_id fk1 o clr_id
fk2 * mnr_id fk2 * mnr_id
refers to tailors refers to manufacturers refers to cobblers
DFo 3-4
Identificadores: El UID primario en el nivel de supertipo crea una clave primaria para cada tabla. Los UID
secundarios del supertipo se convierten en claves únicas en cada tabla.
Relaciones:
• Todas las tablas obtienen una clave ajena para una relación en el nivel de supertipo, con la opcionalidad
original (manufacturers)
• Para las relaciones de los niveles de subtipo, la clave ajena se implanta en la tabla a la que se asigna. Se
retiene la opcionalidad. (tailors, cobblers)
30
Ejercicio del proyecto
• DFo_3_4_Project
– Base de datos de la tienda Oracle Baseball League:
– Aplicación de las reglas de asignación de relaciones para
transformar relaciones
DFo 3-4
31
Resumen
En esta lección, debe haber aprendido lo siguiente:
• Aplicar la asignación de terminología entre los modelos
lógicos y físicos
• Comprender y aplicar las convenciones
de nomenclatura de Oracle para tablas y columnas
utilizadas en los modelos físicos
• Aplicar las reglas de asignación de relaciones
para transformar las relaciones
correctamente
DFo 3-4
32

DFo 3 4 SG Esp

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

DFo 3 4 SG Esp

Cargado por

Copyright:

Formatos disponibles

Fundamentos de bases de datos

EMPLOYEES (EPE) Implementación física:

ERD Diseño físico

Atributo Columna Implantación

UID primario Clave primaria

UID secundario Clave única

Relación Clave ajena

Los atributos se clasifican de una de las siguientes formas:

ID FIRST_NAME LAST_NAME STREET_ADDRESS CITY

– Ejemplo: First name se convierte * last_name

en first_name o fname. * street_address

the EMPLOYEE belong to DEPARTMENT

ACCOUNT located in BANK

REVIEWS (RVW) Key Type Optionality Column name

EMPLOYEE allocated CUBICLE

EMPLOYEES (EPE) CUBICLES (CBE)

Key Type Optionality Column name Key Type Optionality Column

fk1 o cpe_id Key Type Optionality Column name

Identificadores: Los identificadores únicos se transforman en claves primarias y únicas.

SHIRTS (SHT) SHOES (SHE)

refers to tailors refers to manufacturers refers to cobblers

También podría gustarte