Crowdly

Add to Chrome

Бази даних

Looking for Бази даних test answers and solutions? Browse our comprehensive collection of verified answers for Бази даних at do.ipo.kpi.ua.

Get instant access to accurate answers and detailed explanations for your course questions. Our community-driven platform helps students succeed!

Опис (виробництво фармпродукту): облік партій виробництва та використаних інгредієнтів.

Ненормалізоване відношення:

BatchUsage(BatchNo, ProductCode, ProductName, IngredientCode, IngredientName, SupplierCode, SupplierName, Qty, Unit, ProducedAt)

Функціональні залежності (FZ):

1) ProductCode → ProductName
2) IngredientCode → IngredientName, Unit, SupplierCode
3) SupplierCode → SupplierName
4) (BatchNo, IngredientCode) → Qty
5) BatchNo → ProductCode, ProducedAt

Питання: Який варіант розбиття на відношення відповідає переходу до 3НФ/НФБК без втрати інформації та без аномалій?

Product(ProductCode, ProductName)

Ingredient(IngredientCode, IngredientName, Unit, SupplierName)

Batch(BatchNo, ProductCode, ProducedAt)

BatchUsage(BatchNo, IngredientCode, Qty)

E. Правильна відповідь відсутня

Product(ProductCode, ProductName)

Supplier(SupplierCode, SupplierName)

Ingredient(IngredientCode, IngredientName, Unit)

Batch(BatchNo, ProductCode, ProducedAt, SupplierCode)

BatchUsage(BatchNo, IngredientCode, Qty)

Product(ProductCode, ProductName)

Supplier(SupplierCode, SupplierName)

Ingredient(IngredientCode, IngredientName, Unit, SupplierCode)

Batch(BatchNo, ProductCode, ProducedAt)

BatchUsage(BatchNo, IngredientCode, Qty, PK(BatchNo, IngredientCode))

100%

Batch(BatchNo, ProductCode, ProductName, ProducedAt)

Ingredient(IngredientCode, IngredientName, Unit, SupplierName)

BatchUsage(BatchNo, IngredientCode, Qty)

View this question

Предметна область: Видавництво: викладачі, курси та підручники

Опис: Видавництво співпрацює з викладачами та постачає підручники для курсів. Викладач може викладати курс, використовуючи певний підручник. Відомо, що кожен підручник затверджений рівно для одного курсу (але один курс може мати кілька підручників).

Правила/обмеження:

Сутності: Teacher, Course, Textbook, Department, SemesterPlan.
ФЗ у зв’язку використання матеріалу: TextbookId → CourseId (підручник належить одному курсу).
У таблиці TeachingMaterial(TeacherId, CourseId, TextbookId) зберігається факт: викладач використовує підручник на курсі.
Ключі в TeachingMaterial: (TeacherId, CourseId) та (TeacherId, TextbookId).

Питання: Чи забезпечує наведена ER/р‑схема (з таблицею TeachingMaterial(TeacherId, CourseId, TextbookId)) нормальну форму Бойса–Кодда?

Ні, але причина в частковій залежності CourseId → TeacherId, яка порушує 2НФ.

Ні, бо існує ФЗ TextbookId → CourseId, де TextbookId не є суперключем; при цьому схема може залишатися у 3НФ, бо CourseId — ключовий (prime) атрибут.

100%

Так, оскільки кожна нетривіальна ФЗ у TeachingMaterial має ключ зліва.

Правильна відповідь відсутня

Так, але лише якщо додати UNIQUE(TeacherId, CourseId, TextbookId) у TeachingMaterial.

View this question

Опис (SOC / кіберінциденти): Incident, Alert, Asset, Analyst, ResponseAction, Playbook.

Incident–Asset: M:N.

Analyst працює над Incident: M:N; для пари (Incident, Analyst) зберігаються Role, HoursSpent, AssignedAt.

Incident має багато ResponseAction (ExecutedAt, Result).

Питання: Який варіант ER коректно моделює M:N з атрибутами без порушення 3НФ/НФБК?

Incident(IncidentID, Severity, CreatedAt)

Analyst(AnalystID, FullName)

IncidentAnalyst(IncidentID, AnalystID, Role, HoursSpent, AssignedAt, PK(IncidentID, AnalystID))

Asset(AssetID, Hostname)

IncidentAsset(IncidentID, AssetID, PK(IncidentID, AssetID))

ResponseAction(ActionID, IncidentID, ActionType, ExecutedAt, Result)

100%

E. Правильна відповідь відсутня

Incident(IncidentID, Severity, CreatedAt, AnalystID, Role, HoursSpent, AssignedAt)

Analyst(AnalystID, FullName)

Asset(AssetID, Hostname)

IncidentAsset(IncidentID, AssetID)

ResponseAction(ActionID, IncidentID, ActionType, ExecutedAt, Result)

Incident(IncidentID, Severity, CreatedAt)

Analyst(AnalystID, FullName)

IncidentAnalyst(IncidentID, AnalystID, Role, HoursSpent, AssignedAt, PK(IncidentID), UNIQUE(AnalystID))

Asset(AssetID, Hostname)

IncidentAsset(IncidentID, AssetID)

ResponseAction(ActionID, IncidentID, ActionType, ExecutedAt, Result)

Analyst(AnalystID, FullName, Role, HoursSpent, AssignedAt)

Incident(IncidentID, Severity, CreatedAt, AnalystID)

Asset(AssetID, Hostname)

IncidentAsset(IncidentID, AssetID)

ResponseAction(ActionID, IncidentID, ActionType, ExecutedAt, Result)

View this question

Предметна область: міський велопрокат.

Є таблиця Rental(RentalId PK, BikeId, Status, Price, UpdatedAt

) та аудит-таблиця

RentalAudit(AuditId IDENTITY, RentalId, ChangedAt, ChangedBy, OldStatus, NewStatus, OldPrice, NewPrice).

Потрібно у тригері на Rental при UPDATE коректно записати старі та нові значення статусу і ціни.

Який фрагмент для тригера є коректним?

INSERT INTO dbo.RentalAudit(RentalId, ChangedAt, ChangedBy, OldStatus, NewStatus, OldPrice, NewPrice)
SELECT d.RentalId, SYSUTCDATETIME(), SUSER_SNAME(),
       d.Status, d.Status,
       d.Price,  d.Price
FROM deleted d;

DECLARE @RentalId INT, @OldStatus NVARCHAR(20), @NewStatus NVARCHAR(20);
SELECT TOP (1)
  @RentalId = RentalId,
  @OldStatus = Status
FROM deleted;
SELECT TOP (1)
  @NewStatus = Status
FROM inserted;
INSERT INTO dbo.RentalAudit(RentalId, ChangedAt, ChangedBy, OldStatus, NewStatus)
VALUES(@RentalId, SYSUTCDATETIME(), SUSER_SNAME(), @OldStatus, @NewStatus);

INSERT INTO dbo.RentalAudit(RentalId, ChangedAt, ChangedBy, OldStatus, NewStatus, OldPrice, NewPrice)
SELECT i.RentalId, SYSUTCDATETIME(), SUSER_SNAME(),
       i.Status, i.Status,
       i.Price,  i.Price
FROM inserted i;

INSERT INTO dbo.RentalAudit(RentalId, ChangedAt, ChangedBy, OldStatus, NewStatus, OldPrice, NewPrice)
SELECT d.RentalId, SYSUTCDATETIME(), SUSER_SNAME(),
       d.Status, i.Status,
       d.Price,  i.Price
FROM inserted i
JOIN deleted  d ON d.RentalId = i.RentalId
WHERE ISNULL(d.Status,'') <> ISNULL(i.Status,'')
   OR ISNULL(d.Price,0)   <> ISNULL(i.Price,0);

100%

Правильна відповідь відсутня

View this question

Предметна область: інтернет-магазин — повернення товарів.

Сутності та зв’язки:

Sale(SaleId PK, CustomerId FK, SoldAt) — 1:M з SaleLine.

SaleLine(SaleId FK, LineNo, ProductId FK, Qty) — ідентифікація позиції продажу: PK(SaleId, LineNo).

ReturnRequest(ReturnId PK, SaleId FK, RequestedAt, Status) — повернення стосується одного продажу.

ReturnLine — лінії повернення: кожна лінія повернення посилається на конкретну позицію продажу (SaleLine) і містить ReturnedQty.

Запитання: який варіант DDL коректно реалізує таблицю ReturnLine так, щоб посилання на SaleLine було коректним (композитний FK на (SaleId, LineNo)), а ключ повернення був ідентифікований всередині ReturnRequest (PK(ReturnId, LineNo))?

CREATE TABLE dbo.ReturnLine(
    ReturnId      BIGINT NOT NULL,
    LineNo        INT    NOT NULL,
    SaleId        BIGINT NOT NULL,
    SaleLineNo    INT    NOT NULL,
    ReturnedQty   INT    NOT NULL,
    CONSTRAINT PK_ReturnLine PRIMARY KEY (ReturnId, LineNo),
    CONSTRAINT FK_ReturnLine_Return FOREIGN KEY (ReturnId)
        REFERENCES dbo.ReturnRequest(ReturnId),
    CONSTRAINT FK_ReturnLine_SaleLine FOREIGN KEY (SaleId, SaleLineNo)
        REFERENCES dbo.SaleLine(SaleId, LineNo),
    CONSTRAINT CK_ReturnLine_Qty CHECK (ReturnedQty > 0)
);

100%

CREATE TABLE dbo.ReturnLine(
    ReturnId      BIGINT NOT NULL,
    LineNo        INT    NOT NULL,
    SaleId        BIGINT NOT NULL,
    SaleLineNo    INT    NOT NULL,
    ReturnedQty   INT    NOT NULL,
    CONSTRAINT PK_ReturnLine PRIMARY KEY (SaleId, SaleLineNo),
    CONSTRAINT FK_ReturnLine_Return FOREIGN KEY (ReturnId)
        REFERENCES dbo.ReturnRequest(ReturnId),
    CONSTRAINT FK_ReturnLine_SaleLine FOREIGN KEY (SaleId, SaleLineNo)
        REFERENCES dbo.SaleLine(SaleId, LineNo)
);

CREATE TABLE dbo.ReturnLine(
    ReturnId      BIGINT NOT NULL,
    LineNo        INT    NOT NULL,
    SaleId        BIGINT NOT NULL,
    SaleLineNo    INT    NOT NULL,
    ReturnedQty   INT    NOT NULL,
    CONSTRAINT PK_ReturnLine PRIMARY KEY (ReturnId, LineNo),
    CONSTRAINT FK_ReturnLine_Return FOREIGN KEY (ReturnId)
        REFERENCES dbo.ReturnRequest(ReturnId),
    CONSTRAINT FK_ReturnLine_SaleLine FOREIGN KEY (SaleLineNo, SaleId)
        REFERENCES dbo.SaleLine(LineNo, SaleId),
    CONSTRAINT CK_ReturnLine_Qty CHECK (ReturnedQty >= 0)
);

CREATE TABLE dbo.ReturnLine(
    ReturnLineId  BIGINT IDENTITY(1,1) NOT NULL,
    ReturnId      BIGINT NOT NULL,
    SaleId        BIGINT NOT NULL,
    LineNo        INT    NOT NULL,
    ReturnedQty   INT    NOT NULL,
    CONSTRAINT PK_ReturnLine PRIMARY KEY (ReturnLineId),
    CONSTRAINT FK_ReturnLine_Return FOREIGN KEY (ReturnId)
        REFERENCES dbo.ReturnRequest(ReturnId),
    CONSTRAINT FK_ReturnLine_Sale FOREIGN KEY (SaleId)
        REFERENCES dbo.Sale(SaleId)
);

Правильна відповідь відсутня

View this question

Предметна область: розумний будинок — облік споживання електроенергії та виставлення рахунків.

Сутності та зв’язки:

Household(HouseholdId PK, Address, PlanId FK) — 1:M з Meter, 1:M з Invoice.

TariffPlan(PlanId PK, PlanCode UNIQUE, BaseRate DECIMAL(10,4), EffectiveFrom DATE) — 1:M з Household.

Meter(MeterId PK, HouseholdId FK NOT NULL, SerialNo UNIQUE, InstalledOn DATE) — 1:M з Reading.

Reading(MeterId FK, ReadingAt DATETIME2, kWh DECIMAL(12,3)) — для кожного лічильника показник унікальний за часом; kWh не може бути від’ємним.

Запитання: який варіант DDL коректно реалізує таблицю Reading (композитний PK, коректний FK, правило kWh ≥ 0)?

CREATE TABLE dbo.Reading(
    MeterId     INT           NOT NULL,
    ReadingAt   DATETIME2(0)  NOT NULL,
    kWh         DECIMAL(12,3) NULL,
    CONSTRAINT PK_Reading PRIMARY KEY (ReadingAt, MeterId),
    CONSTRAINT FK_Reading_Meter FOREIGN KEY (MeterId) REFERENCES dbo.Household(HouseholdId),
    CONSTRAINT CK_Reading_kWh CHECK (kWh > 0)
);

CREATE TABLE dbo.Reading(
    ReadingId   BIGINT IDENTITY(1,1) NOT NULL,
    MeterId     INT           NOT NULL,
    ReadingAt   DATETIME2(0)  NOT NULL,
    kWh         DECIMAL(12,3) NOT NULL,
    CONSTRAINT PK_Reading PRIMARY KEY (ReadingId),
    CONSTRAINT FK_Reading_Meter FOREIGN KEY (MeterId) REFERENCES dbo.Meter(MeterId),
    CONSTRAINT UQ_Reading UNIQUE (MeterId),
    CONSTRAINT CK_Reading_kWh CHECK (kWh >= 0)
);

Правильна відповідь відсутня

CREATE TABLE dbo.Reading(
    MeterId     INT           NOT NULL,
    ReadingAt   DATETIME2(0)  NOT NULL,
    kWh         DECIMAL(12,3) NOT NULL,
    CONSTRAINT PK_Reading PRIMARY KEY (MeterId, ReadingAt),
    CONSTRAINT FK_Reading_Meter FOREIGN KEY (MeterId) REFERENCES dbo.Meter(MeterId),
    CONSTRAINT CK_Reading_kWh CHECK (kWh >= 0)
);

100%

CREATE TABLE dbo.Reading(
    MeterId     INT           NOT NULL,
    ReadingAt   DATETIME2(0)  NOT NULL,
    kWh         DECIMAL(12,3) NOT NULL,
    CONSTRAINT PK_Reading PRIMARY KEY (MeterId),
    CONSTRAINT FK_Reading_Meter FOREIGN KEY (MeterId) REFERENCES dbo.Meter(MeterId),
    CONSTRAINT CK_Reading_kWh CHECK (kWh >= 0)
);

View this question

Предметна область: біобанк/лабораторія зберігання зразків.

Є базові таблиці:

Donor(DonorCode PK, FullName, BirthDate)

DonorContact(DonorCode FK->Donor, Phone, Email, CONSTRAINT PK_DonorContact PRIMARY KEY(DonorCode, Phone))

Є уявлення:

CREATE VIEW dbo.vDonorContact AS
SELECT d.DonorCode, d.FullName, d.BirthDate, c.Phone, c.Email
FROM dbo.Donor d
JOIN dbo.DonorContact c ON c.DonorCode = d.DonorCode;

Потрібно дозволити INSERT у vDonorContact через INSTEAD OF INSERT тригер так, щоб:

донор додавався один раз (навіть якщо вставляється кілька телефонів одного донора в одному INSERT),

контакти додавались пострічково (multi-row),

не було дублювання Donor по DonorCode.

Який фрагмент DML у тригері є коректним?

MERGE dbo.Donor AS d
USING inserted AS i
ON d.DonorCode = i.DonorCode
WHEN MATCHED THEN
  UPDATE SET d.FullName = i.FullName, d.BirthDate = i.BirthDate
WHEN NOT MATCHED THEN
  INSERT(DonorCode, FullName, BirthDate) VALUES(i.DonorCode, i.FullName, i.BirthDate);
INSERT INTO dbo.DonorContact(DonorCode, Phone, Email)
SELECT TOP (1) i.DonorCode, i.Phone, i.Email
FROM inserted i;

INSERT INTO dbo.Donor(DonorCode, FullName, BirthDate)
SELECT i.DonorCode, MAX(i.FullName), MAX(i.BirthDate)
FROM inserted i
WHERE NOT EXISTS (SELECT 1 FROM dbo.Donor d WHERE d.DonorCode = i.DonorCode)
GROUP BY i.DonorCode;
INSERT INTO dbo.DonorContact(DonorCode, Phone, Email)
SELECT i.DonorCode, i.Phone, i.Email
FROM inserted i;

100%

Правильна відповідь відсутня

INSERT INTO dbo.Donor(DonorCode, FullName, BirthDate)
SELECT DISTINCT i.DonorCode, i.FullName, i.BirthDate
FROM inserted i;
INSERT INTO dbo.DonorContact(DonorCode, Phone, Email)
SELECT i.DonorCode, i.Phone, i.Email
FROM inserted i
WHERE i.Phone IS NOT NULL AND i.Email IS NOT NULL;

INSERT INTO dbo.Donor(DonorCode, FullName, BirthDate)
SELECT i.DonorCode, i.FullName, i.BirthDate
FROM inserted i;
INSERT INTO dbo.DonorContact(DonorCode, Phone, Email)
SELECT i.DonorCode, i.Phone, i.Email
FROM inserted i;

View this question

Опис (грантова система): FundingProgram, Call (конкурс у межах програми і року), ApplicantOrg, Project, Review, Expert.

CallNo унікальний лише в межах (FundingProgram, Year).

ProjectCode унікальний лише в межах Call.

Review зберігає Score і SubmittedAt для пари (Project, Expert).

Питання: Яка ER-модель найкоректніше відображає унікальності та зв’язки без прихованих транзитивних залежностей?

FundingProgram(ProgramID, ProgramName)

Call(CallID, ProgramName, Year, CallNo)

Project(ProjectID, CallID, ProjectCode, ApplicantOrgID)

ApplicantOrg(ApplicantOrgID, OrgName)

Expert(ExpertID, FullName)

Review(ReviewID, ProjectID, ExpertID, Score, SubmittedAt)

E. Правильна відповідь відсутня

FundingProgram(ProgramID, ProgramName, Year)

Call(CallID, ProgramID, CallNo)

Project(ProjectID, CallID, ProjectCode, ApplicantOrgID)

ApplicantOrg(ApplicantOrgID, OrgName)

Expert(ExpertID, FullName)

Review(ReviewID, ProjectID, ExpertID, Score, SubmittedAt)

FundingProgram(ProgramID, ProgramName)

Call(CallID, ProgramID, Year, CallNo, UNIQUE(ProgramID, Year, CallNo))

ApplicantOrg(ApplicantOrgID, OrgName)

Project(ProjectID, CallID, ProjectCode, ApplicantOrgID, UNIQUE(CallID, ProjectCode))

Expert(ExpertID, FullName)

Review(ProjectID, ExpertID, Score, SubmittedAt, PK(ProjectID, ExpertID))

100%

FundingProgram(ProgramID, ProgramName)

Call(CallID, ProgramID, Year, CallNo, UNIQUE(CallNo))

Project(ProjectID, CallID, ProjectCode, ApplicantOrgID, UNIQUE(ProjectCode))

ApplicantOrg(ApplicantOrgID, OrgName)

Expert(ExpertID, FullName)

Review(ReviewID, ProjectID, ExpertID, Score, SubmittedAt)

View this question

Предметна область: клінічна лабораторія — замовлення аналізів.

Сутності та зв’язки:

LabOrder(OrderId PK, PatientId FK, CreatedAt) — 1:M з OrderTest.

TestCatalog(TestId PK, Code UNIQUE, Name) — довідник аналізів.

OrderTest — позиції замовлення: кожне замовлення має багато позицій; позиція посилається на один аналіз; для позиції зберігається LineNo (порядковий номер у замовленні), Priority, RequestedQty.

Запитання: який варіант DDL коректно реалізує таблицю OrderTest як слабку/залежну сутність з ідентифікацією всередині замовлення (ключ — (OrderId, LineNo)), і водночас задає правильні зовнішні ключі на LabOrder і TestCatalog?

CREATE TABLE dbo.OrderTest(
    OrderId       BIGINT        NOT NULL,
    LineNo        INT           NOT NULL,
    TestId        INT           NOT NULL,
    Priority      TINYINT       NOT NULL,
    RequestedQty  INT           NOT NULL,
    CONSTRAINT PK_OrderTest PRIMARY KEY (OrderId, LineNo),
    CONSTRAINT FK_OrderTest_Order FOREIGN KEY (OrderId) REFERENCES dbo.LabOrder(OrderId),
    CONSTRAINT FK_OrderTest_Test  FOREIGN KEY (TestId)  REFERENCES dbo.TestCatalog(TestId),
    CONSTRAINT CK_OrderTest_Qty CHECK (RequestedQty > 0)
);

100%

CREATE TABLE dbo.OrderTest(
    OrderId       BIGINT        NOT NULL,
    LineNo        INT           NOT NULL,
    TestId        INT           NOT NULL,
    Priority      TINYINT       NOT NULL,
    RequestedQty  INT           NOT NULL,
    CONSTRAINT PK_OrderTest PRIMARY KEY (OrderId, TestId),
    CONSTRAINT FK_OrderTest_Order FOREIGN KEY (OrderId) REFERENCES dbo.LabOrder(OrderId),
    CONSTRAINT FK_OrderTest_Test  FOREIGN KEY (TestId)  REFERENCES dbo.TestCatalog(TestId)
);

CREATE TABLE dbo.OrderTest(
    OrderTestId   BIGINT IDENTITY(1,1) NOT NULL,
    OrderId       BIGINT        NOT NULL,
    LineNo        INT           NOT NULL,
    TestId        INT           NOT NULL,
    Priority      TINYINT       NOT NULL,
    RequestedQty  INT           NOT NULL,
    CONSTRAINT PK_OrderTest PRIMARY KEY (OrderTestId),
    CONSTRAINT FK_OrderTest_Order FOREIGN KEY (OrderId) REFERENCES dbo.LabOrder(OrderId),
    CONSTRAINT FK_OrderTest_Test  FOREIGN KEY (TestId)  REFERENCES dbo.TestCatalog(TestId),
    CONSTRAINT UQ_OrderTest UNIQUE (OrderId)
);

Правильна відповідь відсутня

CREATE TABLE dbo.OrderTest(
    OrderId       BIGINT        NOT NULL,
    LineNo        INT           NOT NULL,
    TestId        INT           NOT NULL,
    Priority      TINYINT       NOT NULL,
    RequestedQty  INT           NOT NULL,
    CONSTRAINT PK_OrderTest PRIMARY KEY (OrderId, LineNo),
    CONSTRAINT FK_OrderTest_Order FOREIGN KEY (OrderId) REFERENCES dbo.TestCatalog(TestId),
    CONSTRAINT FK_OrderTest_Test  FOREIGN KEY (TestId)  REFERENCES dbo.LabOrder(OrderId)
);

View this question

Предметна область: Смарт‑ферма: зрошення полів і витрати ресурсів

Опис: Ферма має поля, культури, датчики вологості та події поливу. Поле може змінювати культуру по сезонах. Один полив може використовувати кілька джерел води (колодязь/резервуар) у певних пропорціях, для кожної пари «подія поливу–джерело» фіксується обсяг та якість води.

Правила/обмеження:

Поле має внутрішній код, унікальний в межах ферми: UQ(FarmId, FieldCode).
Посів (Field–Crop) є M:N з атрибутами SeasonYear, PlantedAt, AreaHa (асоціативна сутність).
Полив (IrrigationEvent) виконується на конкретному полі, має StartedAt/EndedAt.
Використання води є M:N між IrrigationEvent і WaterSource з атрибутами VolumeM3, SalinityPpm, PK(IrrigationEventId, WaterSourceId).
Не зберігати SeasonYear/AreaHa в Field або Crop; не зберігати VolumeM3 в WaterSource або IrrigationEvent без асоціативної сутності.

Питання: Який варіант ER‑моделі коректно відображає M:N з атрибутами та унікальність коду поля?

Farm(FarmId PK, FarmCode UQ, FarmName, RegionCode)
Field(FieldId PK, FarmId FK→Farm, FieldCode UQ, FieldName, AreaHaTotal)
Crop(CropId PK, CropCode UQ, CropName, SeasonYear, PlantedAt, AreaHa)
Sensor(SensorId PK, FieldId FK→Field, SensorSerial UQ, InstalledAt)
IrrigationEvent(IrrigationEventId PK, FieldId FK→Field, StartedAt, EndedAt, WaterSourceId FK→WaterSource, VolumeM3, SalinityPpm)
WaterSource(WaterSourceId PK, SourceCode UQ, SourceType, LocationNote)
Зв’язки: Field–Crop (1:M), IrrigationEvent–WaterSource (1:M)

Farm(FarmId PK, FarmCode UQ, FarmName, RegionCode)
Field(FieldId PK, FarmId FK→Farm, FieldCode, FieldName, AreaHaTotal, UQ(FarmId, FieldCode))
Crop(CropId PK, CropCode UQ, CropName)
FieldCrop(FieldId FK→Field, CropId FK→Crop, SeasonYear, PlantedAt, AreaHa, PK(FieldId, CropId, SeasonYear))
Sensor(SensorId PK, FieldId FK→Field, SensorSerial UQ, InstalledAt)
IrrigationEvent(IrrigationEventId PK, FieldId FK→Field, StartedAt, EndedAt, OperatorUserId)
WaterSource(WaterSourceId PK, SourceCode UQ, SourceType, LocationNote)
IrrigationWater(IrrigationEventId FK→IrrigationEvent, WaterSourceId FK→WaterSource, VolumeM3, SalinityPpm, PK(IrrigationEventId, WaterSourceId))
Зв’язки: Farm–Field (1:M), Field–Crop (M:N через FieldCrop), Field–Sensor (1:M), Field–IrrigationEvent (1:M), IrrigationEvent–WaterSource (M:N через IrrigationWater)

100%

Farm(FarmId PK, FarmCode UQ, FarmName, RegionCode)
Field(FieldId PK, FarmId FK→Farm, FieldCode, FieldName, UQ(FarmId, FieldCode))
Crop(CropId PK, CropCode UQ, CropName)
FieldCrop(FieldCropId PK, FieldId FK→Field, CropId FK→Crop, SeasonYear, PlantedAt, AreaHa, UQ(FieldId, SeasonYear))
Sensor(SensorId PK, FieldId FK→Field, SensorSerial UQ, InstalledAt)
IrrigationEvent(IrrigationEventId PK, FieldId FK→Field, StartedAt, EndedAt)
WaterSource(WaterSourceId PK, SourceCode UQ, SourceType, LocationNote)
IrrigationWater(IrrigationEventId FK→IrrigationEvent, WaterSourceId FK→WaterSource, VolumeM3, SalinityPpm, PK(IrrigationEventId))

Правильна відповідь відсутня

Farm(FarmId PK, FarmCode UQ, FarmName, RegionCode)
Field(FieldId PK, FarmId FK→Farm, FieldCode, FieldName, FarmName, UQ(FieldCode))
Crop(CropId PK, CropCode UQ, CropName)
FieldCrop(FieldId FK→Field, CropId FK→Crop, SeasonYear, PlantedAt, AreaHa, PK(FieldId, SeasonYear))
Sensor(SensorId PK, FieldId FK→Field, SensorSerial UQ, InstalledAt)
IrrigationEvent(IrrigationEventId PK, FieldId FK→Field, StartedAt, EndedAt)
WaterSource(WaterSourceId PK, SourceCode UQ, SourceType, LocationNote)
IrrigationWater(IrrigationEventId FK→IrrigationEvent, WaterSourceId FK→WaterSource, VolumeM3, SalinityPpm, UQ(WaterSourceId))
Зв’язки: IrrigationEvent–WaterSource (M:N через IrrigationWater)

View this question

Want instant access to all verified answers on do.ipo.kpi.ua?

Get Unlimited Answers To Exam Questions - Install Crowdly Extension Now!

Add to Chrome

Telegram Instagram TikTok Question Bank