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