Проектирование хранилищ данных для приложений систем деловой осведомленности (Business Intelligence Systems) - ответы

Исходное отношение:

Преподаватель (Личный_#, Фамилия, Должность, Оклад, Кафедра, Телефон )

Результирующие отношения:/

Преподаватель(Личный_#, Фамилия, Должность, Кафедра)

Должность (Должность, Оклад)

Кафедра (Кафедра, Телефон)

Комментарий к ответу: Отношение Преподаватель содержит транзитивные зависимости: Личный_#→​Кафедра→​Телефон и Личный_#→​Должность→​Оклад. Это может привести к следующим аномалиям:

Устранение аномалий заключается в выполнении трех проекций отношения.

SELECT AVG(Col1) AS "?????" FROM Table WHERE ID BETWEEN MAX(ID) / 2 AND (MAX(ID) / 2) + SIGN(MAX{(ID) +1 % 2)				

SELECT VENDOR_CODE, PRODUCT_CODE, PRODUCT_DESCFROM VENDOR, PRODUCTWHERE VENDOR.VENDOR_CODE = PRODUCT.VENDOR_CODE AND VENDOR.VENDOR_CODE = "100";				

"У него есть и недостатки - данные могут дублироваться и быть несогласованными в разных киосках данных".

Исходное отношение:

Курсовой_проект (Преподаватель - Предмет - Студент)

Иванов - Тема1 - Петрова

Фролов - Тема1 - Исаев

Антонов - Тема1 - Сидоров

Иванов - Тема2 - Ивлева

Фролов - Тема2 - Степанов

Фролов - Тема3 - Мусин

Антонов - Тема3 - Сац

Результирующие отношения:

Руководство (Преподаватель, Предмет)

Выполнение (Студент, Предмет)

Комментарий к ответу: На роль ключа отношения Курсовой_проект претендует набор атрибутов {Преподаватель, Предмет}. Студент выполняет только один проект, один и тот же проект может выполняться несколькими студентами у разных преподавателей. Отношение содержит следующие ФЗ: {Преподаватель, Предмет} -> Студент и Студент -> Предмет.

Отношение находится в 3НФ и не содержит частичных и транзитивных ФЗ. Однако наличие ФЗ части составного ключа от неключевого атрибута может привести к следующим аномалиям:

Устранение аномалий заключается в удалении ФЗ ключа от неключевого атрибута.

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);		

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

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

SELECT Time, Region, Department, SUM(Profit) AS Profit FROM sales   GROUP BY Time, ROLLUP (Region, Department);				

SELECT OrderID, ProductID, OrderQty	,SUM(OrderQty) OVER(PARTITION BY OrderID) AS 'Итого'	,AVG(OrderQty) OVER(PARTITION BY OrderID) AS 'Среднее'FROM OrderDetailWHERE OrderID IN(43659,43664);			

SELECT р_productkey, SUM(s_amount) as 'Суммарное количество',   RANK() OVER (ORDER BY SUM(s_amount) DESC) AS 'rank_all',   DENSE_RANK() OVER (ORDER BY SUM(s_amount) DESC) AS 'rank_dense'FROM salesGROUP BY р_productkey;			

SELECT VENDOR_CODE, PRODUCT_CODE, PRODUCT_DESCFROM VENDOR, PRODUCTWHERE VENDOR.VENDOR_CODE = PRODUCT.VENDOR_CODE AND VENDOR.VENDOR_CODE = "100";				

SELECT Time, Region, Department, SUM(Profit) AS Profit,  GROUPING (Time) as T,   GROUPING (Region) as R,   GROUPING (Department) as D  FROM SalesGROUP BY ROLLUP (Time, Region, Department);		

SELECT р_productkey, SUM(s_amount) as 'Суммарное количество',   RANK() OVER (ORDER BY SUM(s_amount) DESC) AS 'rank_all',   DENSE_RANK() OVER (ORDER BY SUM(s_amount) DESC) AS 'rank_dense'FROM salesGROUP BY р_productkey;			

"Достоинством такого подхода является получение более согласованных определений данных и бизнес-правил организации в самом начале работы над созданием ХД. Стоимость начального планирования и проектирования может оказаться достаточно высокой. Для этого подхода характерны большие затраты времени, что откладывает начало реализации и задерживает возврат инвестиций. Этот подход хорошо работает в организациях с хорошо организованной информационно-вычислительной структурой, когда программно-аппаратная платформа определена, существуют слаженно работающие источники данных".

SELECT * FROM east_sales@icp.ac.ru WHERE LOC = 'EAST'UNION ALLSELECT * FROM west_sales@ioc.ac.ru WHERE LOC = 'WEST';		

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);		

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

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

SELECT Time, Region, Department, SUM(Profit) AS Profit FROM sales   GROUP BY CUBE(Time, Region, Department);				

SELECT Region. MIN(Population) AS Minimum, MAX(Populations)AS Maximum, AVG(Population) AS Average. VAR(Population) AS VarianceFROM Region GROUP BY Region ORDER BY Maximum DESC;				

SELECT VENDOR_CODE, PRODUCT_CODE, PRODUCT_DESCFROM VENDOR, PRODUCTWHERE VENDOR.VENDOR_CODE = PRODUCT.VENDOR_CODE AND VENDOR.VENDOR_CODE = "100";			

Исходное отношение:

Преподаватель (Фамилия, Группа, Предмет )

Результирующие отношения:

Преподаватель_группа (Фамилия, Группа )

Преподаватель_предмет (Фамилия, Предмет )

Комментарий к ответу: Отношение Преподаватель содержит две многозначные ФЗ: Фамилия ->-> Группа и Фамилия ->-> Предмет. Это приводит к аномалии включения: если у преподавателя появляется новая группа, в отношение приходится добавлять несколько кортежей (по числу читаемых им предметов). Устранение аномалии заключается в выделении МФЗ в отдельное отношение.

SELECT COUNT(*) FROM EMPLOYEE WHERE Ename LIKE 'C%';		

Исходное отношение:

Преподаватель_предмет (Личный_#, Предмет, Часы, Фамилия, Должность, Оклад, Кафедра, Телефон )

Результирующие отношения:

Преподаватель (Личный_#, Фамилия, Должность, Оклад, Кафедра, Телефон )

Предмет(Личный_#, Предмет, Часы )

Комментарий к ответу: Отношение Преподаватель_Предмет содержит частичные ФЗ: пять последних неключевых атрибутов зависят от части ключа Личный_#. Это может привести к следующим аномалиям:

Устранение аномалий заключается в выполнении двух проекций отношения.

SELECT Time, Region, Department, SUM(Profit) AS Profit FROM sales   GROUP BY ROLLUP(Time, Region, Department);		

SELECT r_regionkey, p_productkey, s_amount, s_profit,   RANK() OVER (ORDER BY s_amount DESC, s_profit DESC) AS 'Ранг по востоку'FROM region, product, salesWHERE region.r_regionkey = sales.s_regionkey AND product.p_productkey = sales.s_productkey AND r_regionkey = 'Восток';			

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);		

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

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

"Этот подход требует детального планирования и проектирования ХД в рамках ИТ – проекта до начала выполнения проекта".

(data integrity constraints) относятся к значениям данных в некоторых колонках и определяются в спецификации колонки с помощью элементов SQL

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);		

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

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