Здравствуйте.
переделываю базу данных, по сути состоящую из одной таблицы (штук 55 полей)
OrderNumber, Distributor, PartNumber,PartDescription, License_quantity, Ship_Date, Serial_number,
RequestDate, CustomerName, CompanyName, Address, City, PostCode, Country, Phone, Fax, Email,
ReasonNewKey, HardwareID, IssueDate, LicenseKey, ReasonReplacementKey1, R1HardwareID, R1IssueDate, R1LicenseKey, ReasonReplacementKey2, R2HardwareID, R2IssueDate,R2LicenseKey,...
, ReasonReplacementN, RnHardwareID, RnIssueDate, RnLicense key.

 Короче все сделано в одну линию. работают люди на етой базе уже лет 8. Проблемы  начались когда количество ключей на замену превышает N. (N = 5 

OrderNumber уникальный, заказ может включать несколько Serial_number.
Каждый Serial_number уникальный, отсылается только одному CompanyName, но может иметь несколько License_quantity. На каждый License_quantity дается один новый ключ, который в последствии может заменятся по заросу от пользователя (указывается ReasonReplacementKey)
На данный момент для каждого OrderNumber имеется [Кол-во Serial_number в заказе]*License_quantity  записей + еще записи, когда когда количество ключей на замену превышает N,
оператор начинает новую строку.


Я разделил таблицу на: 1.Заказы (OrderNumber(PK),Distributor,PartNumber,PartDescription,License_quantity, Ship_Date, Serial_number(FK))
                                        2. Пользователи
(Serial_number,CustomerName, CompanyName, Address, City, PostCode, Country, Phone, Fax, Email)
                                        3. LicenseKeys
(Serial_number, ReasonID, HardwareID, IssueDate, LicenseKey, Comments)
                                        4. IssueDescriptions (ReasonID(PK) , Reason Description ( 6 значений :
новый ключ, неисправность, апгрейд...)
Связь 1->2 и 1->3 по Serial_number. Связь 3->4 должна быть по IssueID, но не могу создать, так как не могу определить PK в таблице 3.
проблема, что:
-если License_quantity > 1, то запросы на ключи может слать один и тот же чел (админ). 
-hardware ID не уникальный номер,
- LicenseKey зависит от hardware ID ( при одинаковых hardware ID и ключи одинаковые)

Вот и ломаю голову как ето все получше скомпоновать/разделить   

Спасибо если кто поможет. или попытается.
Да, и база - мдб в Аксесе, исходная таблица ~ 1.5 млн записей, переносится будет на SQL server 2000 ( Access adp project)

Значит так. Начнем с того, что забудем про существование базы и соответственно таблицы.

Объясняй сущность процесса и его физику.

1.Фирма рассылает софт по диллерам, либо сама продает. Каждый заказ имеет:
- номер заказа,
- Имя диллера (компания)
- абривиатуру софта ( Part name)
- Описание софта (soft description)
- серийный номер продукта
- колво купленных лицензий.

Заказы проходят по MySAP, информация обозначеная выше берется оттуда и заносится в базу оператором. Лицензии могут продаваться отдельно, т.е их число может увеличится. Допустим купили софт с SDK & one user licenses,
попробовали, понравилось купили еще 100 лизензий на тот же серийник.

2. Конечные пользователи присылают запросы по мейлу на активацыю софта. запрос включает в себя:
- Имя конечного пользователя 
- Название компании
- адрес, город, почтовый индекс, страну, телефон, факс, емейл
- серийный номер софта
- hardware ID, строка генерируемая софтом при инсталяции.
- причину запроса ( [New purchase, Upgrade] при первой инсталяции, [hardware failure, hardware upgrade, ... ] для последующих переустановок.
- для ключ на замену, предидущее hardware ID с етого компа.

hardware ID может быть одинаковым для разных серийных номеров/ компов, но никогда для одного и тогоже компа. Оператор сверяет серийник, проверяет кол-во лицензий вносит данные в таблицу, генерирует ключ, вносит его тоже в таблицу отсылает ключ пользователю. Для софта с многими лицензиями, все запросы могут приходить от одного чела (админ и т.д.), те первые персональные данные те же, включая [Имя конечного пользователя]

Ну вроде все.

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


Это сообщение отредактировал(а) alexIrish - 31.1.2008, 16:03

Вот как я это представляю

Присоединённый файл ( Кол-во скачиваний: 14 )
 Sales.rar 10,98 Kb

Вот один из возможных вариантов:

Сущности:

- операция (основная сущность)
- дилер
- клиент
- софт
- лицензия

Дилер - в принципе сторонняя характеристика заказа. Если продажа идет через него - он фигурирует в заказе, если напрямую - не фигурирует.
Клиент - конечная точка заказа. С ним все понятно.
Софт - в принципе чисто справочное данное.
Лицензия - на самом деле сюда входит и экземпляр продаваемого софта (эдакий виртуальный тип лицензии "коробка")...
Операция - единичное действие, т.е. действие с элементарной единицей товара с одним клиентом в рамках одного заказа.

Вот и получается.

Основная таблица - это таблица операций. Заказов. При этом один реальный заказ может порождать несколько строк в таблице (скажем строка софта с коробкой и строка лицензий) с одним номером заказа (но разными ИД, есссно).
К ней линкуется таблица Дилеров (если прямая продажа - то Null).
К ней линкуется таблица Клиентов (как я понимаю, дилер клиента не скрывает, иначе невозможно обеспечить запросы по ре- или просто активации).
К ней линкуется таблица Софта (тупо о каком программном продукте речь).
К ней линкуется таблица типов операций. Тут собственно и описывается суть того что делается (продается коробка, продается доп. лицензия, выполняется активация или реактивация, апгрейд, продление и т.п.). В зависимости от типа операции дополнительные поля в основной таблице либо заполняются/не заполняются, либо по-разному интерпретируются. К ней уже линкуется таблица типов лицензий (Null, если действие не предусматривает лицензии, скажем продажа коробки с софтом или документацией) со своими характеристиками (тоже возможны разные интерпретации в зависимости от типа лицензии). Либо эта парочка формируется как одна таблица, а не две.

Добавлено через 4 минуты и 21 секунду

Боюсь, твоя схема не предусматривает кучи операций... Что делать, если по одному заказу проходит два софта? Где в ней будет отображаться замена версии и соответствующая замена лицензии? И так далее... я уж не говорю о том, что у тебя будут плодиться копии записей о покупателях.

тут я сомневаюсь... как я понял продажа идет только через него!

ну это я все в одну сущность кинул..

Мне так не показалось:



Мне это не кажется правильным... хотя почему нет?

Rodman, можно попросить ваш пример в формате а2000 выложить?
Нигде рядом нету версии выше:(

Большое спасибо за рекомендации, сейчас буду ваять, наваяю, обьявлю.
Еще раз спасибо.

вот... а2000

Присоединённый файл ( Кол-во скачиваний: 4 )
 Sales1.rar 10,71 Kb

Привет всем.
И попытался подумать и решил сделать так ( см. файл)
Почему:
-Все- таки, уникальная сущность ето заказ, его номер. Он может включать сколькко угодно 
софта/серийников но сам заказ всегда один. Инфа в таблице заказов чисто справочная. Роль играет только номер заказа
- ну и дальше, на каждый серийный номер можно повесить [LicenseQty] пользователей.
- соответственно каждый серийный номер не должен иметь больше  чем [LicenseQty] операций с
IssueDescriptionID =(1- "New purchase" , 2 - " Upgrade")

Ваше мнение?

Да и сразу спрошу: в таблицах ("Oreders", "LicenseOperations", "Users") поля ...ID - автономера.
В аксесе нет проблем, а вот в SQL server, по моему нет такого типа данных:(


Это сообщение отредактировал(а) alexIrish - 1.2.2008, 12:33

Присоединённый файл ( Кол-во скачиваний: 7 )
 Ralations.rar 40,51 Kb

Заказ представляет из себя ГРУППУ элементарных действий.

Akina, спасибо за Identity.

Физически да, но в данном случае таблица заказов дает информацию что такой заказ существует.
Сам процесс продажи софта в данном случае играет роль индикатора: либо софт был продан (соответственно существует номер заказа) либо нет. 
Подумав,перекинул поля PartNumber, Description в таблицу SerialNumbers, так как ето всетаки инфа о софте, как и серийный номер 

Ваяем дальше!

Снова здрасьте.
Базу я разделил, сделал форму.  С новыми записями все в порядке. 
А вот как перелопатить милион записей из старой таблицы в новые?  
Там и по ключам ошибки получаю ( в старой таблице есть дублирующиеся данные по заказам и серийным номерам. ) 
Я ручками ето год делать буду. 
У кого есть идеи?
Для наглядности выложил базу со старой таблицей "BigTable" и всеми новыми созданными на данный момент.



Присоединённый файл ( Кол-во скачиваний: 6 )
 db1.rar 15,45 Kb

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

И по структуре.

1) Непонятна связь SerialNumbers - Users. Это что - один сериал может быть на несколько юзеров?
2) Аналогично по SerialNumbers - LicenseOpreations... впрочем, тут я как раз могу представить - сперва поставили, потом переставили или продлили...
3) Связь LicenseOpreations - IssueDescription, по-моему, просто не туда воткнута.
4) Связь SerialNumbers - Orders вообще лишена смысла, ибо ни на одной стороне нет ключевого поля, хотя в каждой из таблиц оно есть.

Но если ЭТО вдруг начнет работать... впрочем, ты еще запросов не начал писАть...