Решите задачу разрешения связи многие-ко-многим для следующей ситуации. Дано отношение...

Решите задачу разрешения связи многие-ко-многим для следующей ситуации. Дано отношение многие ко многим

Требуется разрешить это отношение.

Решение.

create table CUSTOMER(CUSTOMER_NO		NUMBER(6) 		not null,CUSTOMER_NAME		VARCHAR2(45)	null,CUSTOMER_ADDRESS	VARCHAR2(35)	null,CUSTOMER_CITY		VARCHAR2(45)	null,CUSTOMER_STATE	CHAR(2)		null,CUSTOMER_ZIP		NUMBER(5)		null,primary key (CUSTOMER_NO))create table SALESMAN(SALESMAN_NO		NUMBER(6)		not null,SALESMAN_NAME 	VARCHAR2(45) 	null,SALESMAN_EMP_NO	NUMBER(6)		null,SALESMAN_YTD_SALES	NUMBER(9,2)	null,SALESMAN_QUOTA	NUMBER(6)		null,SALESMAN_PROD_GRP	CHAR(8)		null,primary key (SALESMAN_NO))create table CUSTOMER_ SALESMAN(CUSTOMER_NO		NUMBER(6)		not null,SALESMAN_NO		NUMBER(6)		not null)

Решите задачу разрешения связи многие-ко-многим для следующей ситуации. Дано отношение многие ко многим

Требуется разрешить это отношение.

Решение.

create table CUSTOMER(CUSTOMER_NO		NUMBER(6) 		not null,CUSTOMER_NAME		VARCHAR2(45)	null,CUSTOMER_ADDRESS	VARCHAR2(35)	null,CUSTOMER_CITY		VARCHAR2(45)	null,CUSTOMER_STATE	CHAR(2)		null,CUSTOMER_ZIP		NUMBER(5)		null,primary key (CUSTOMER_NO))create table SALESMAN(SALESMAN_NO		NUMBER(6)		not null,SALESMAN_NAME 	VARCHAR2(45) 	null,SALESMAN_EMP_NO	NUMBER(6)		null,SALESMAN_YTD_SALES	NUMBER(9,2)	null,SALESMAN_PROD_GRP	CHAR(8)		null,primary key (SALESMAN_NO))create table CUSTOMER_ SALESMAN(CUSTOMER_NO	NUMBER(6)			not null,SALESMAN_NO	NUMBER(6)			not null,SALESMAN_QUOTA	NUMBER(6)		null,primary key (CUSTOMER_NO, SALESMAN_NO),foreing key (CUSTOMER_NO) references CUSTOMER,foreign key  (SALESMAN_NO) references SALESMAN)

Решите задачу разрешения связи многие-ко-многим для следующей ситуации. Дано отношение многие ко многим

Требуется разрешить это отношение.

Решение.

create table CUSTOMER(CUSTOMER_NO		NUMBER(6) 		not null,CUSTOMER_NAME		VARCHAR2(45)	null,CUSTOMER_ADDRESS	VARCHAR2(35)	null,CUSTOMER_CITY		VARCHAR2(45)	null,CUSTOMER_STATE	CHAR(2)		null,CUSTOMER_ZIP		NUMBER(5)		null,primary key (CUSTOMER_NO))create table SALESMAN(SALESMAN_NO		NUMBER(6)		not null,SALESMAN_NAME 	VARCHAR2(45) 	null,SALESMAN_EMP_NO	NUMBER(6)		null,SALESMAN_YTD_SALES	NUMBER(9,2)	null,SALESMAN_QUOTA	NUMBER(6)		null,SALESMAN_PROD_GRP	CHAR(8)		null,primary key (SALESMAN_NO))create table CUSTOMER_ SALESMAN(CUSTOMER_NO	NUMBER(6)		not null,SALESMAN_NO	NUMBER(6)		not null,primary key (CUSTOMER_NO, SALESMAN_NO),foreing key (CUSTOMER_NO) references CUSTOMER,foreign key  (SALESMAN_NO) references SALESMAN)

Рассмотрим базу данных обработки заказов и создадим индексный кластер для хранения одной из таблиц базы данных - Customer.

CREATE CLUSTER cust_c (cust_id varchar(8))INDEX;CREATE INDEX cust_c_id ON CLUSTER cust_c;CREATE TABLE cust (cust_id 	varchar2(8) NOT NULL REFERENCES customers,ent#		number	NOT NULL,date_ent	date		NOT NULL,comment	varchar2(60)	NOT NULL,…PRIMARY KEY(cust_id, ent#)) CLUSTER cust_c (cust_id);

Созданная таблица кластеризована по колонке cust_id, и все специальные записи о клиента в колонке comment будут расположены в одной странице физической базы данных либо в смежных страницах. Их можно выбрать за одну операцию поиска по индексу:

SELECT date_ent, comment FROM cust_c WHERE cust_id=:cur_cust;

Комментарий. Ограничение первичного ключа в операторе CREATE сделано, чтобы избежать создания второго индекса.

Является ли такое решение преимуществом с точки зрения утверждения: "Все записи о клиентах выбираются для ежегодного отчета".

Рассмотрим базу данных обработки заказов и создадим индексный кластер для хранения одной из таблиц базы данных - Customer.

CREATE CLUSTER cust_c (cust_id varchar(8))INDEX;CREATE INDEX cust_c_id ON CLUSTER cust_c;CREATE TABLE cust (cust_id 	varchar2(8) NOT NULL REFERENCES customers,ent#		number	NOT NULL,date_ent	date		NOT NULL,comment	varchar2(60)	NOT NULL,…PRIMARY KEY(cust_id, ent#)) CLUSTER cust_c (cust_id);

Созданная таблица кластеризована по колонке cust_id, и все специальные записи о клиента в колонке comment будут расположены в одной странице физической базы данных, либо в смежных страницах. Их можно выбрать за одну операцию поиска по индексу:

SELECT date_ent, comment FROM cust_c WHERE cust_id=:cur_cust;

Комментарий. Ограничение первичного ключа в операторе CREATE сделано, чтобы избежать создания второго индекса.

Является ли такое решение преимуществом с точки зрения утверждения: "Очень немного строк о клиентах имеют специальные записи о клиенте".

Рассмотрим базу данных обработки заказов и создадим индексный кластер для хранения одной из таблиц базы данных - Customer.

CREATE CLUSTER cust_c (cust_id varchar(8))INDEX;CREATE INDEX cust_c_id ON CLUSTER cust_c;CREATE TABLE cust (cust_id 	varchar2(8) NOT NULL REFERENCES customers,ent#		number	NOT NULL,date_ent	date		NOT NULL,comment	varchar2(60)	NOT NULL,…PRIMARY KEY(cust_id, ent#)) CLUSTER cust_c (cust_id);

Созданная таблица кластеризована по колонке cust_id, и все специальные записи о клиента в колонке comment будут расположены в одной странице физической базы данных, либо в смежных страницах. Их можно выбрать за одну операцию поиска по индексу:

SELECT date_ent, comment FROM cust_c WHERE cust_id=:cur_cust;

Комментарий. Ограничение первичного ключа в операторе CREATE сделано, чтобы избежать создания второго индекса.

Является ли такое решение преимуществом с точки зрения утверждения: "При выборке специальных записей о клиенте для клиента выбираются все такие записи".

Рассмотрим базу данных обработки заказов и создадим индексный кластер для хранения одной из таблиц базы данных - Customer.

CREATE CLUSTER cust_c (cust_id varchar(8))INDEX;CREATE INDEX cust_c_id ON CLUSTER cust_c;CREATE TABLE cust (cust_id 	varchar2(8) NOT NULL REFERENCES customers,ent#		number	NOT NULL,date_ent	date		NOT NULL,comment	varchar2(60)	NOT NULL,…PRIMARY KEY(cust_id, ent#)) CLUSTER cust_c (cust_id);

Созданная таблица кластеризована по колонке cust_id, и все специальные записи о клиента в колонке comment будут расположены в одной странице физической базы данных, либо в смежных страницах. Их можно выбрать за одну операцию поиска по индексу:

SELECT date_ent, comment FROM cust_c WHERE cust_id=:cur_cust;

Комментарий. Ограничение первичного ключа в операторе CREATE сделано, чтобы избежать создания второго индекса.

Является ли такое решение преимуществом с точки зрения утверждения: "Строки, имеющие специальные записи о клиенте, имеют более одной записи о клиенте".

Дана таблица PROJECT, созданная командой

CREATE TABLE PROJECT (PROJNO  	char(8) NOT NULL,PNAME  	char(25),BUDGET  	dec(9,2),PRIMARY KEY (PROJNO));

Ниже приведено изменение в определении таблицы для того, чтобы иметь возможность различать законченные проекты и переносить их в таблицу PROJECT_OLD. Упрощает ли данное изменение сопровождение таблицы?

CREATE TABLE PROJECT (PROJNO  	char(8) NOT NULL,FINISH	char(1) NOT NULL,PNAME  	char(25),BUDGET  	dec(9,2),PRIMARY KEY (PROJNO, FINISH));

Комментарий к Задаче 6. Добавление дополнительных колонок в первичный ключ приведет к дополнительным накладным расходам. Отбор записей для перенесения и последующего удаления с помощью переменной типа дата менее выгоден, чем использование односимвольной переменной. Спорным остается вопрос наложения на переменную FINISH ограничения NOT NULL. Это целесообразно сделать, но это приводит к лишней операции при вводе проекта - явного указания, что он не завершен.

Дана таблица PROJECT, созданная командой

CREATE TABLE PROJECT (PROJNO  	char(8) NOT NULL,PNAME  	char(25),BUDGET  	dec(9,2),PRIMARY KEY (PROJNO));

Ниже приведено изменение в определении таблицы для того, чтобы иметь возможность различать законченные проекты и переносить их в таблицу PROJECT_OLD. Упрощает ли данное изменение сопровождение таблицы?

CREATE TABLE PROJECT (PROJNO  	char(8) NOT NULL,S_DATE	date NOT NULL,F_DATE	date,PNAME  	char(25),BUDGET  	dec(9,2),PRIMARY KEY (PROJNO));

Комментарий к Задаче 6. Добавление дополнительных колонок в первичный ключ приведет к дополнительным накладным расходам. Отбор записей для перенесения и последующего удаления с помощью переменной типа дата менее выгоден, чем использование односимвольной переменной. Спорным остается вопрос наложения на переменную FINISH ограничения NOT NULL. Это целесообразно сделать, но это приводит к лишней операции при вводе проекта - явного указания, что он не завершен.

Дана таблица PROJECT, созданная командой

CREATE TABLE PROJECT (PROJNO  	char(8) NOT NULL,PNAME  	char(25),BUDGET  	dec(9,2),PRIMARY KEY (PROJNO));

Ниже приведено изменение в определении таблицы для того, чтобы иметь возможность различать законченные проекты и переносить их в таблицу PROJECT_OLD. Упрощает ли данное изменение сопровождение таблицы?

CREATE TABLE PROJECT (PROJNO  	char(8) NOT NULL,S_DATE	date NOT NULL,F_DATE	date,PNAME  	char(25),BUDGET  	dec(9,2),PRIMARY KEY (PROJNO, S_DATE));

Комментарий к Задаче 6. Добавление дополнительных колонок в первичный ключ приведет к дополнительным накладным расходам. Отбор записей для перенесения и последующего удаления с помощью переменной типа дата менее выгоден, чем использование односимвольной переменной. Спорным остается вопрос наложения на переменную FINISH ограничения NOT NULL. Это целесообразно сделать, но это приводит к лишней операции при вводе проекта - явного указания, что он не завершен.

Основы проектирования реляционных баз данных