База ответов ИНТУИТ

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

<<- Назад к вопросам

Для достижения 3НФ необходимо, чтобы:

(Отметьте один правильный вариант ответа.)

Варианты ответа
данные уникально представлялись таблицами, таблица находилась в 1НФ и 2НФ(Верный ответ)
данные уникально располагались в отдельных полях только трех таблиц
неключевые атрибуты не зависели друг от друга, таблица находилась в 1НФ
данные соответствовали бизнес-правилам организации
Похожие вопросы
Чтобы разместить объект базы данных в определенном табличном пространстве, необходимо …
Определите порядок действий при создании базовых таблиц реляционной базы данных
Номер шага алгоритмаДействие
1IАФормирование списка имен таблиц и их сокращений в словаре данных
2IIБИдентификация реляционной таблицы
3IIIВПроверка: число базовых таблиц соответствует числу отношений логической модели реляционной базы данных
4IVГФормирование списка имен колонок и их сокращений в словаре данных
5VДОпределение колонок для базовых таблиц
6VIЕОпределение типов данных колонкам
7VIIЖПроверка списка имен в словаре данных, чтобы избежать конфликтов имен в базе данных в целом
8VIIIЗВыборочное добавление
Дана таблица 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)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,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. Это целесообразно сделать, но это приводит к лишней операции при вводе проекта - явного указания, что он не завершен.

Рассмотрим базу данных обработки заказов и создадим индексный кластер для хранения одной из таблиц базы данных - 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 сделано, чтобы избежать создания второго индекса.

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