Помогите пожалуйста создать базу. Есть база такой вот структуры, удоволетворяет всем бизнес-правилам, но уж очень тяжело с ней работать.
CREATE TABLE [dbo].[Place] (
[YEAR] [smallint] NOT NULL ,
[MONTH] [smallint] NOT NULL ,
[CEX] [smallint] NOT NULL ,
[GORIZ] [smallint] NOT NULL ,
[PLACE_Id] [int] IDENTITY (1, 1) NOT NULL PRIMARY KEY CLUSTERED )

CREATE TABLE [dbo].[WORK1] (
[PLACE_ID] [int] NOT NULL FOREIGN KEY REFERENCES [dbo].[Place] ([PLACE_ID]),
[NUM] [smallint] NOT NULL ,
[W1P1] [smallint] NOT NULL ,
[W1P2] [smallint] NOT NULL ,
[W1P3] [smallint] NOT NULL ,
[W1P4] [smallint] NOT NULL,
[ROW_ID] [int] IDENTITY (1, 1) NOT NULL )
CREATE TABLE [dbo].[WORK2] (
[PLACE_ID] [int] NOT NULL FOREIGN KEY REFERENCES [dbo].[Place] ([PLACE_ID]),
[NUM] [smallint] NOT NULL ,
[W2P1] [smallint] NOT NULL ,
[W2P2] [smallint] NOT NULL ,
[W2P3] [smallint] NOT NULL ,
[W2P4] [smallint] NOT NULL
[ROW_ID] [int] IDENTITY (1, 1) NOT NULL )
CREATE TABLE [dbo].[WORK3] (
[PLACE_ID] [int] NOT NULL FOREIGN KEY REFERENCES [dbo].[Place] ([PLAC_ID]),
[NUM] [smallint] NOT NULL ,
[W3P1] [smallint] NOT NULL ,
[W3P2] [smallint] NOT NULL ,
[W3P3] [smallint] NOT NULL
[ROW_ID] [int] IDENTITY (1, 1) NOT NULL )
CREATE TABLE [dbo].[WORK4] (
[PLACE_ID] [int] NOT NULL FOREIGN KEY REFERENCES [dbo].[Place] ([PLAC_ID]),
[NUM] [smallint] NOT NULL ,
[W4P1] [smallint] NOT NULL
[ROW_ID][int] IDENTITY (1, 1) NOT NULL)
CREATE TABLE [dbo].[Remain] (
[Place_Id] [int] NOT NULL ,
[Rem1W1P1] [numeric](6, 2) NULL ,
[Rem1W2P2] [numeric](6, 2) NULL ,
[AddW1P1] [numeric](6, 2) NULL ,
[AddW2P2] [numeric](6, 2) NULL ,
[RedW1P1] [numeric](5, 1) NULL ,
[RedW2P2] [numeric](5, 1) NULL ,
[Rem2W1P2] [numeric](6, 2) NULL ,
[Rem2W2P2] [numeric](6, 2) NULL )
Смысл данных в таблицах Place Cex-цех где работала установка(цехов всего 5), Goriz-горизонт в этом цехе(в каждом цехе несколько горизонтов, до 10). В одном месяце установка может работать на разных горизонтах в одном цехе, и может работать в разных цехах. Таблицы типа WORKn описывают разные виды работ выполняемые установками. Например WORK1 содержит данные по выполненным работам первого вида в течении месяца, поля типа WnPn-хорактеризуют этот вид работ. Num-номер установки(в основном но не всегда работают в течении месяца только в одном цехе, в каждом цехе их примерно по 15). Place_Id - понятно из связи. Одному "месту" в каждой из таблиц "Работ" может соответствоть по несколько записей. Например установка в мая в сехе №1 на 1-горизонте выполняла как первый вид работ так и второй. Причем, например в таблице WORK1 одной записи из Place будет соответствовать 2 записи, т.к при выполнении работы 1-го вида показатель W1P3 имел вначале одно значение, а потом изменился на другое, и это надо учитывать. Правила обеспечивающие верность хранимых данных в других таблицах типа WORKn такие же. Remain-таблица остатков. Содержит суммарные данные по горизонту в каждом цехе за месяц. Rem2***-остаток на конец месяца. В конце текущего этот остаток становится остатком на начало следующего - Rem1***. AddW1P1 - хоть по умолчанию и должен содержать суму по горизонту в цехе по строкам из таблици WORK1 значений показателя W1P1, но может и довольно часто редактируется(такова технология работ), с AddW2P2 то-же самое. С RedW1P1 и RedW2P2 все также как с пердыдущими, только берутся они из неуказанных здесь таблиц(описывающих работу установок другого вида). С таблицей Remain и основные проблеммы. Не понятно когда и как лучше ее заполнять(может тригера написать на изменение в таблицах WORK1 и WORK2 подсчитывающие сумму и корректирующие таблицу Remain, толи из клеенского приложение это делать), ну в общем с этой таблицей все как то очень плохо. Также мне кажется что в запросе вообще невозможно правильно соеденить например таблици Place, Work1 и Work2, т.к. одной записи из таблицы Place в таблице WORK1 может соответсвовать 2 записи, а в таблице WORK2 только одна. Как здесь сопоставлять строки учитывая номер установки вообще не понятно. Я думаю что все проблеммы из -за неправильной структуры базы, но исправить это не хватает знаний. Помогите пожалуйста.

Извеняюсь за не правильный скрипт для базы, вот рабочий и схема в виде рисунка. Правда ни как не могу понять как прикрепить рисунок.

Установка это экскаватор. В течении одного месяца он может перемещатся по горизонтам внутри карьера и более того может быть переведен в другой карьер.
Экскаватор тогружает продукцию разного вида или выполняет несколько типов работ. WORK1-описывает отгрузку руды на ж.д. транспорт, W1P1 - количество вагонов отгруженой руды (шт.), W2P2 - загрузка вагонов(м.куб.), W3P3 - удельный вес руды, W4P4 - расстояние от места погрузки вагонов(экскаватора) до места выгрузки вагонов(км.). Если экскаватор грузил руду в одном цехе на одном и том-же горизонте но с разным удельным весом то в таблице должно быть 2-ве записи, т.к. этот показатель влияет на учет руды в тоннах. Если экскаватор грузил руду в одном цехе на одном и том-же горизонте с одним и тем-же удельным весом но растояние бало разное то в таблице должно быть 2-ве записи, т.к. этот показатель оценивает объем работ выполненный железнодорожниками. Следовательно получаем такое ограничение для таблицы WORK1:
WORK2 - описывает отгрузку вскрыши на ж.д. транспорт, здесь все тоже самое что и при отгрузке руды.
WORK3- отгрузка вскрыши на автотранспорт. W3P1-объем отгруженой вскрыши(м.куб.), W3P2 - удельный вес вскрыши, W3P2 - растояние(км.). Т.е.
WORK4 - бестранспортная перевалка. W4P1 - объем в м.куб
В таблица Remain - хронятся данные по остаткам руды и вскрыши по горизонту
Rem1W1P1-остаток руды на начало месяца, [Rem1W2P2] - остаток вскрыши на начало месяца, [AddW1P1]-прибыло(взорвано) руды на горизонте в течении месяца, [AddW2P2]-прибыло(взорвано) вскрыши на горизонте в течении месяца, [RedW1P1]-убыло(отгружено) руды(SUM(W1P1) с группировкой по горизонту в карьере за месяц), [RedW2P2]-убыло(отгружено) вскрыши (SUM(W2P1*W2P2+W3P1) с группировкой по горизонту в карьере за месяц),
[Rem2W1P2]-остаток руды на конец месяца, [Rem2W2P2]-остаток вскрыши на конец месяца). Уникальность записи обеспечивается первичным ключом.
Вот такие бизнес-правила. Оговорюсь сразу, сложившаяся система учета вынуждает хранить именно такие показатели, и менят ее я не могу.
Если вести справочник установок типа (Год,Месяц,Цех..дальше не знаю что) то по моему это излишне все усложнит, и как понять что и где он отгружал если в течении месяца он работал в двух карьерах(по суткам учет не ведется). Если объеденить таблицы WORKn в одну, как пердложил Станислав C, то ведь работы оцениваются по разному-различные типы данных для хранения показателей разное их количество и как при этом обеспечить бизнес-правила(уникальность записи). Самое удобное для анализа данных вводимых данных, непосредственно при вводе свернуть таблицы WORKn в одну но так-
(Place_Id, Num, W1P1, W1P2, W1P3, W1P4, W2P1, W2P2, ....., W4P1) но как при этом обеспечить уникальность строки согластно бизнес-правилам я не смог догадаться. Если посмотреть внимательно то если соеденить требования на уникальность строки от таблицы WORK1 с требованиями таблицы WORK2 и т.д., то это не будет правильным.

Да дествительно я как то не заметил, что при обьединении 3-х таблиц с уникальностью записи все впарядке, спасибо. На самом деле можно сказать что ни чего еще не написано. Идет переделка проекта написанного на FoxPro(dos). Там база такая (Year, Month, Cex, Goriz, Num, W1P1, W1P2, W1P3, W1P4, W2P1, W2P2, ....., W4P1) и таблицы Remain. Она очень удобна анализа данных непосредственно при вводе, но ни как не соответствует бизнес-правилам, постоянное дублирование данных. То что представил за существующую БД. Это мой вариант, по моему такая схема хорошо потдерживает бизнес-правила(это касается таблиц работ). Перечень показателей действительно был стабилен несколько лет, но пришло новое руководство и система учета подвержена изменениям, понятно что переждать это у меня нет возможность. Хочу еще уточноть - хоть в таблицах и есть везде м.куб. но загрузка думпкар(вагонов) и объем добытой вскрыши, перевалки показатели по сути разные и выражаются несопостовимыми по парядку числами(numeric(3,1) и int(6) - то что я в базе везде указал smallint - это так для упрощения). На счет: "Как здесь сопоставлять строки учитывая номер установки вообще не понятно." - при написании клиенского приложения я сталкиваюсь с не разрешимой проблеммой, с помощью SQL-запросов.
Самая удобная форма для ввода(на чем настаевает заказчик)
НомКолДумпРудЗагрДумпРудУдРудРастРудКолДумпВскрыш...Перевал2010030.63.51210...600002012030.63.57-...-4-----...150000итого по гориз.... А при моем варианте надо соединять таблицы, например при соединении WORK1 и WORK2, если в одной таблице одной строке из Place соответсвует две строки, для экскаватора №20, а в WORK2 для этой же строки из Place и для этого-же экскаватора №20 только одна то как бы я этого не хотел в результате SQL-запроса я получу произведение числа записей из первой таблицы на число записей из второй. Т.е. необходим достаточно сложный алгоритм на стороне клиента с применением временных таблиц причем рассположенных на HDD т.к. в DELPHI нет таблиц в памяти. Ну и куча других сложностей.
Может лучше Num вынести в таблицу Place, а таблицу Remain вообще не связывать. А как бы сделали вы и почему именно так. Подскажите пожалуйста.
Уточненеие: на самом деле за то что была отгружена руда или вскрыша на ж.д. транспорт отвечает показатель "удельный вес" если от 2.5 до 3.25 - вскрыша больше руда, на автотранспорт грузят только вскрышу, при перевалка просто не важно что переваливают. В Remain столбци Rem2W1P2 и Rem2W2P2 - чисто вычесляемые, но их присутствие в таблице облегчает перенос остатков с конца месяца на начало следующего.

Извеняюсь, привошу форму без сокращений(под формой должна быть подобной EXCEL-евской таблице, в которой они сечас проводят анализ распечатывают результат, а потом "вбивают" его в FoxPro-шную базу)
НомКолДумпРудЗагрДумпРудУдРуд РастРудКолДумпВскрышЖдЗагрДумпВскрышЖдУдРудВскрышЖдРастРудВскрышЖдОбъемВскрышАвтУдВскрышАвтРастВскрышЖдПеревал 2010030.63.5121030.63.210500003.17600002010030.63.510-------- 4-----------150000по 100 гориз200---10---50000--21000020----10030.63.210500003.171215030.63.46-------- 8--------700003.212по 130 гориз150---100---120000---.......................................
К сожалению я не могу четко понять ваш способ записи функциональных зависимостей.

Перевалка: (Место, Ном)->(Объем)
ОтгрузкаАвто: (Место,Ном,УдРуд,РастРуд) -> Объем
ОтгрузкаЖелдор: (Место,Ном,УдРуд,РастРуд) -> Объем,КолДумп
поясните пожалуйста как это трактуется.
Во втором варианте не понял куда деть перевалку
Если можно но поподробней пожалуйста.