Нормализация БД

Добрый день, уважаемые форумчане!
Хочу спросить у вас совета как довести БД "Поверка/калибровка" до ума.

Изначально было 3 сущности:
номенклатура(данные по приборам)
протоколы(данные проведенных измерений, результат измерений, дата)
погода(журнал атмосферных условий работ)

первую сущность вроде как раскидал, а вот со 2 и 3-ей проблемы.
Я так понял связь м/у номенклатура и протоколы будет N:M, значит надо реализовать через третью таблицу ... но голова уже не варит, а скоро сдавать (как всегда)
Прошу Ваши комментарии по организации БД, советы, кто может - помощь в реализации
Заранее благодарен!

Вложения

2003.zip (22.4 Кб, 18 просмотров)

0

Не хочется уже повторятся про поля подстановок в таблицах. Что касается вашей БД, то нужно знать хоть немного предметную область, чтобы вам помочь. Например погода ваша измеряется прибором из номенклатуры? Тогда в таблице Погода должен быть код номенклатуры.

1

Попробую описать область:
На предприятии работает поверитель={Фамилия, Имя, Отчество}, выполняющий поверку приборам.
Информация на каждый прибор хранится в номенклатурной карточке={уникальная единица оборудования, наименование, тип прибора, сер. номер, нижний и верхний пределы измерений, единицы измеряемой величины, вид работ, класс точности, местоположение прибора}.
Так же ведется обязательный журнал погодных_условий={Дата, температура, влажность, давление в кПа, давление в мм.рт.ст, напряжение сети, частота сети}.
Проведение поверки заключается в проведении измерений: на прибор подается эталонное значение, результаты измерений записываются в протокол={номер протокола, ПервичнПериодич, некоторые данные из "Карточки" (наименование, тип прибора, серийн. номер, класс точности, местоположение), данные из "Погода"(кроме даты), дата, заключение о годности}

Данные в "Погода" спускают сверху, проводить измерений не нужно. Первичный ключь по дате позволяет однозначно выбрать кортеж.
В "номенклатура" уже есть уникальный ключь - единица оборудования ( 20030001, 20030002 и т.д.), который позволяет однозначно определить оборудование по этой единице. По коду_подстановки выделил отдельные сущности, чтоб можно было добавлять или изменять.

Могу все объяснить, только вопросы задайте. Если есть немного времени - через скайп, имя как и тут.

0

Единица оборудования - сейчас в базе стоит поле счетчик, но потом будет 20030001, 20030002 ...

Я так понял, данные из погоды можно и не линковать, через запрос потом выбрать.
Но по какому полю связать "протоколы" и "номенклатура" ...
Там получается, что одному номеру протокола может принадлежать только одна ЕО (на каждый прибор отдельный протокол). Выходит связь 1:1? Но тогда в Протоколе нужно создать такие же поля...
Немного обновил базу, дописал комментарии в "Описание" в режиме "контруктор".

Вложения

2003.zip (24.5 Кб, 9 просмотров)

0

Сообщение от murcha86 По коду_подстановки выделил отдельные сущности, чтоб можно было добавлять или изменять.

Ничего вручную добавлять и изменять в таблицы не нужно и поля подстановки там категорически не нужны. Для добавлять и изменять существуют формы, в них поля со списком, подчинённые формы и т.д. А вот результат использования ваших подстановок:
Поля подстановки в таблицах

по протоколам - у вас испорченные протоколы могут быть? тогда связь нужна один - ко - многим. Я не понял, как вы собираетесь привязать погоду? может код_погоды нужен тогда в протоколах? Или по дате потом будет выборка? Код_ео вообще-то в протоколах - внешний ключ, он не может быть ключевым полем, а вот ключевое поле как раз в данный момент в протоколах отсутствует.

1

Испорченных быть не может, там в итоге либо прибор прошел поверку, либо нет (поле годность)
Погоду связал по дате (правильно ли так?), не понял как потом по индексу будет выбирать.

Миниатюры

 

Вложения

2003.zip (22.7 Кб, 6 просмотров)

0

Тогда скорее вот так:

Вложения

123.rar (18.8 Кб, 13 просмотров)

1

Поле подстановки убрал, сделал по коду. Правильно или опять шаг назад?
И как, допустим, выбрать Все ЕО с определенным КТ и наименованием?

alvk, может хоть на небольшой материальной основе поможешь с правильной структурой и формами?

Миниатюры

 

Вложения

1234.zip (29.2 Кб, 12 просмотров)

0

Сообщение от murcha86 Поле подстановки убрал, сделал по коду. Правильно или опять шаг назад?

Не все, КТ и местоположение остались, должен быть только код. Тема называется нормализация, какие могут были поля подстановки? Любые многозначные поля - денормализация.

Сообщение от murcha86 И как, допустим, выбрать Все ЕО с определенным КТ и наименованием?

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

Сообщение от murcha86 alvk, может хоть на небольшой материальной основе поможешь с правильной структурой и формами?

Даже не знаю, что на это ответить, задание до конца не ясно, времени опять же неизвестно сколько займёт, да и просто времени нет. Неужели сам не справишся? Книжки есть, примеров на форуме масса, что не получится - всегда помогут.

1

Перечитал все еще раз, переделал схему данных.
Нашел похожую даже.
Правильно ли переделал?

Миниатюры

   

0

1.Справочник проверок и средства измерений нужно объединить в одну таблицу, раз уж у вас там точно один - к - одному.
2. Почему связи таблиц идут не по коду, а по каким-то ВидИзм, модель и т.д.?

1

Сообщение от alvk 1.Справочник проверок и средства измерений нужно объединить в одну таблицу, раз уж у вас там точно один - к - одному.

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

2

Бывает
Переделал, жду реплик.
Вопросы по статье:

Чуствую у меня тоже где-то должна быть табличка вида "Дисциплина по преподавателям"...

Миниатюры

 

0

Сообщение от murcha86 Т.е. таблицу "справочник моделей" нужно разбить еще на "Класс точности", "Единица измерений"? Там же тоже данные одни и те же и не изменяются ... Чуствую у меня тоже где-то должна быть табличка вида "Дисциплина по преподавателям"...

Не "разбить" на таблицы, а добавить справочники "Класс точности", "Единица измерений". Разумное решение.

Некоторое удивление вызывает наличие полей [Напряжение] и [Частота] в журнале погоды. Какое отношение имеют эти характеристики к погоде? Похоже, что эти параметры задают условия проведения проверки, равно как и погода, но к погоде они как относятся? Может быть журнал погоды переименовать в Условия поверок? И потом - если важны условия поверок и они вносятся в БД, то зачем они нужны, если на них нет никакой реакции? Другое дело, если бы были таблицы коректировки измерений в зависимости от условий наблюдений, тогда существание в БД данных по условиям оправдано. А сейчас не очень понятна цель их хранения.
Также не вижу в БД таблиц тарировки приборов. Известно, что любые поверочные приборы со временем меняются в их измерения вносится погрешность. С помощью обязательных поверок выявляется систематическая погрешность и добавляется к натурным измерениям. А здесь нет учета погрешности измерений, как будто приборы идеальны и у них нет отклонений.
И еще момент. Измерения всегда делаются в несколько попыток с тем, чтобы избежать случайных ошибок. Если работа не студентческая, а производственная, то конечно важно записывать не осредненные, по многим попыткам, величины, а реальные измерения. Если, разумеется, такие записи существуют.

Добавлено через 5 минут
Да. и еще поле [Тип] в справочнике моделей, просится в отдельный справочник. Правда, не знаю о чем речь и сужу только по названию поля :-)

1

Спасибо всем участвовавшим в дискуссии! Я наконец-то понял что хочу
Разбил на справочники, связал по коду. Так же объединил МодельСИ и СписокСИ, убрав поле Модель.
Убрал за ненадобностью, т.к. просто копировал набор полей из SAP R3.
Журнал погоды это таблица фактов, в дальнейшем будет использована для составления протоколов с помощью отчетов, никаких действий не требуется - проверка условий относится к подготовительным операциям (если не соответствуют - то поверку не проводят).
Добавил в "Журнал поверок" поле "поправка", но сомневаюсь в нужности. Поправку можно сделать уже при калибровке прибора (начальной настройке). Она имеет место разве что в геометрических измерениях и весовых...
Измерения добавил (см. скрин). Теперь осталось с запросами разобраться ...
PS: Задача студенческо-производственная, решил не тратить курсовой напрасно и автоматизировать немножко себе работу.

Миниатюры

 

0

Продолжим-с ... как реализовать такую штуку (будет использоваться для вычислений на форме):

Есть измеряемый диапазон, внутри диапазона может быть множество данных - измеряемых точек (см.скрин в предыдущем сообщении)
МаксЗнач - максимальное значение каждого элемента в диапазоне
СрЗнач - среднее значение по диапазону
ЗначН

Насколько я понял можно сделать это через SQL, но запрос составить не могу.
1) Берем данные из 1-го диапазона.
2) Ищем МаксЗнач (по модулю, т.к. от +20 до -20, к примеру)
3) Ищем СрЗнач по всему диапазону
4) Вычитаем из МаксЗнач(число по модулю) значение СрЗнач, полученное значение запоминаем как ЗначН

Дальше нужно сравнить уже на форме МаксЗнач и ЗначН с предельно допустимыми и выделить цветом если превышают ...

0

Up ...

0