Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Профессионалы, раскритикуйте модель складской БД для курсовой
|
|||
|---|---|---|---|
|
#18+
/*Господа профессионалы! Пожалуйста, наведите критику на модель БД аптеки малого мед предприятия для моей курсовой работы. С форума SQL меня послали на ... на ВАШ форум. Нет никакой бухгалтерии. Медикаменты отпускаются в отделения клиники по цене прихода. Беспокоят следующие моменты: 1. Нет ли ошибки в том, что я вывел в "Шапку накладной" сотрудника и фирму контрагента из таблицы "Сотрудник-Фирма"? 2. Все ли я правильно сделал в области "ПАРТИЯ", "СТРОКА", "НАКЛАДНАЯ", "СКЛАД"? 3. В связи с тем, что Медикаменты отпускаются по цене прихода (нет торговли) верно ли я определил таблицу "СТРОКА". Или правильнее убрать из "ПАРТИЯ" атрибут цена и сделать его частью составного ключа в табб "СТРОКА" (ID_накладной, ID_партии, цена), или правильнее сделать цену и количество, зависимыми от ID_строка и связать связать таб. "СТРОКА" идентиф. связью с "НАКЛАДНОЙ" и неидент. связью с "ПАРТИЕЙ". Имеет ли выбор принципиальное значение? 3. Нужна ли вообще таблица "СКЛАД" или с точки зрения оптимизации (или нормализации) лучше все делать через "вьюху". Форум я перечитал. Много мнений, много дискуссий, "много топиков намусолено" (цит.). Решение как всегда индивидуальное в каждом случае. Но что бы ВЫ посоветовали студенту. 4. Вообще все ли достаточно оптимизировано для работы 2-го курса? В курсовом задании это основная задача. 5. А может быть я нагородил вообще что-то не то? 6. Последнее. Сейчас разбираюся со списанием и формированием расходных накладных. Прочитал про ФИФО. Кажется это не мой случай. Думаю решить задачу отгрузкой в первую очередь партий, в которых критичны сроки годности. Очень поможете, если дадите подсказку. БУДУ РАД ЛЮБЫМ ЗАМЕЧАНИЯМ И СОВЕТАМ. С УВАЖЕНИЕМ, URA*/ --- название единицы измерения товара CREATE TABLE EDIZMNAZV ( edizmnazv_id int IDENTITY(1,1), edizmnazv_name varchar(40) NOT NULL DEFAULT 'упаковка', PRIMARY KEY NONCLUSTERED (edizmnazv_id) ) go ---единица измерения товара CREATE TABLE EDIZM ( edizm_id int IDENTITY(1,1), edizmnazv_id int NOT NULL, edizm_kol int NOT NULL DEFAULT 20, PRIMARY KEY NONCLUSTERED (edizm_id), FOREIGN KEY (edizmnazv_id) REFERENCES EDIZMNAZV ) go ---название медикамента CREATE TABLE NAZV ( nazv_id int IDENTITY(1,1), nazv_name varchar(40) NOT NULL, PRIMARY KEY (nazv_id) ) go ---форма медикамента напр ампулы CREATE TABLE FORM ( form_id int IDENTITY(1,1), form_name varchar(20) NOT NULL, PRIMARY KEY NONCLUSTERED (form_id) ) go ---медикамент CREATE TABLE MD ( md_id int IDENTITY(1,1), nazv_id int NOT NULL, form_id int NOT NULL DEFAULT 1, md_doze varchar(40) NOT NULL, PRIMARY KEY NONCLUSTERED (md_id), FOREIGN KEY (nazv_id) REFERENCES NAZV, FOREIGN KEY (form_id) REFERENCES FORM ) go ---партия товара CREATE TABLE PART ( part_id int IDENTITY(1,1), md_id int NOT NULL, edizm_id int NOT NULL, part_godo datetime NOT NULL, part_zena money NOT NULL, PRIMARY KEY NONCLUSTERED (part_id), FOREIGN KEY (edizm_id) REFERENCES EDIZM, FOREIGN KEY (md_id) REFERENCES MD ) go ---должность сотрудника фирмы поставщика или получателя CREATE TABLE DOL ( dol_id int IDENTITY(1,1), dol_name varchar(40) NOT NULL, PRIMARY KEY NONCLUSTERED (dol_id) ) go ---адрес фирмы поставщика или получателя CREATE TABLE ADR ( adr_id int IDENTITY(1,1), adr_street varchar(40) NOT NULL, adr_city varchar(40) NOT NULL DEFAULT 'Moscow', adr_house varchar(4) NOT NULL, adr_office varchar(4) NOT NULL, PRIMARY KEY NONCLUSTERED (adr_id) ) go ---фирма поставщика или получателя CREATE TABLE FIRM ( firm_id int IDENTITY(1,1), firm_name varchar(100) NOT NULL, adr_id int NOT NULL, PRIMARY KEY NONCLUSTERED (firm_id), FOREIGN KEY (adr_id) REFERENCES ADR ) go ---сотрудник CREATE TABLE SOT ( sot_id int IDENTITY(1,1), sot_fam varchar(50) NOT NULL, sot_name varchar(50) NOT NULL, sot_secname varchar(50) NOT NULL, PRIMARY KEY NONCLUSTERED (sot_id) ) go ---связка сотрудник фирмы CREATE TABLE FIRM_SOT ( firm_id int NOT NULL, sot_id int NOT NULL, dol_id int NOT NULL, PRIMARY KEY NONCLUSTERED (firm_id, sot_id), FOREIGN KEY (dol_id) REFERENCES DOL, FOREIGN KEY (firm_id) REFERENCES FIRM, FOREIGN KEY (sot_id) REFERENCES SOT ) go ---шапка накладной CREATE TABLE NK ( nk_id int IDENTITY(1,1), nk_numb int NOT NULL, nk_tip varchar(1) NOT NULL DEFAULT 'p', nk_data datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, firm_id int NOT NULL, sot_id int NOT NULL, nk_provedena bit NOT NULL DEFAULT 0, PRIMARY KEY NONCLUSTERED (nk_id), FOREIGN KEY (firm_id, sot_id) REFERENCES FIRM_SOT ) go ---строка накладной или табличная часть CREATE TABLE ST ( nk_id int NOT NULL, part_id int NOT NULL, st_kol int NOT NULL DEFAULT 1, PRIMARY KEY NONCLUSTERED (nk_id, part_id), FOREIGN KEY (part_id) REFERENCES PART, FOREIGN KEY (nk_id) REFERENCES NK ) go ---телефон CREATE TABLE TEL ( tel_id int IDENTITY(1,1), tel_code varchar(20) NOT NULL DEFAULT '095', tel_num varchar(20) NOT NULL, PRIMARY KEY NONCLUSTERED (tel_id) ) go ---связка телефон сотрудника CREATE TABLE TEL_SOT ( sot_id int NOT NULL, tel_id int NOT NULL, PRIMARY KEY NONCLUSTERED (sot_id, tel_id), FOREIGN KEY (sot_id) REFERENCES SOT, FOREIGN KEY (tel_id) REFERENCES TEL ) go ---название группы медикамента CREATE TABLE GRUP ( grup_id int IDENTITY(1,1), grup_name varchar(40) NOT NULL, PRIMARY KEY NONCLUSTERED (grup_id) ) go ---таблица остатков CREATE TABLE OSTATOK ( ostatok_id int IDENTITY(1,1), part_id int NOT NULL, ostatok int NOT NULL, PRIMARY KEY NONCLUSTERED (ostatok_id), FOREIGN KEY (part_id) REFERENCES PART ) go ---название типа группы медикамента CREATE TABLE TIPGRUP ( tipgrup_id int IDENTITY(1,1), tipgrup_name varchar(40) NOT NULL, PRIMARY KEY NONCLUSTERED (tipgrup_id) ) go ---группы медикамента MD одновр может принадлежать разным CREATE TABLE GRUP_MD ( grup_id int NOT NULL, md_id int NOT NULL, tipgrup_id int NOT NULL, PRIMARY KEY NONCLUSTERED (grup_id, md_id), FOREIGN KEY (tipgrup_id) REFERENCES TIPGRUP, FOREIGN KEY (md_id) REFERENCES MD, FOREIGN KEY (grup_id) REFERENCES GRUP ) go ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2005, 16:24 |
|
||
|
Профессионалы, раскритикуйте модель складской БД для курсовой
|
|||
|---|---|---|---|
|
#18+
Возможно, был не прав, посылаю в догонку ERwin file ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2005, 17:27 |
|
||
|
Профессионалы, раскритикуйте модель складской БД для курсовой
|
|||
|---|---|---|---|
|
#18+
Опишите связи между сущностями в форме Баркера: Каждый <Сущность1> должен/может <Отношение> один [или несколько] <Сущность2> Всегда рекомендую это делать, а уж в учебных целях - обязательно. Тогда будет ясно, что критиковать, а многое проясниться уже при попытках дать максимально точную формулировку связи. Например связь "связка сотрудник фирмы" -- "Шапка накладной" что означает? Получил, Отпустил, Разрешил? СКЛАД нужен, если складов несколько. С ценами все описанные варианты имеют право на существование - они соответсвуют разным бизнес-правилам. Успехов! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2005, 17:53 |
|
||
|
Профессионалы, раскритикуйте модель складской БД для курсовой
|
|||
|---|---|---|---|
|
#18+
ModelR-у. Спасибо за совет попробую постдеть, почитать, написать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2005, 18:14 |
|
||
|
Профессионалы, раскритикуйте модель складской БД для курсовой
|
|||
|---|---|---|---|
|
#18+
>>4. Вообще все ли достаточно оптимизировано для работы 2-го курса? А какой критерий оптимальности ? Скорость доступа к данным, простота запросов, управляемость... Я бы произвел денормализацию, но не думаю что это приветствуется в курсовых работах. Денормализацию следующим образом: таблицы-справочники EDIZMNAZV, EDIZM, FORM оставить, таблицу NAZV убрать (если только нет вариантов, когда медикаменты с одинаковым названием имеют разные, ну например 'единицы измерения товара'), причем таблицы EDIZMNAZV и EDIZM слить в одну (опять же, если нет одинаковых 'названий единиц измерения товара' с различными 'единицами измерения товара') и в таблицу MD писать значения вместо id записи справочника. А вот список возможных значений брать из справочника (реализуется через клиентский интерфейс). Например: пользователь вводит новую товарную позицию и ему надо заполнить поле 'единицы измерения товара' - он не может ввести новую единицу, только выбрать из выпадающего списка 'единицу измерения товара', список берется из таблицы EDIZM Например он выбрал 'упак.' - в таблицу MD именно это и пишем, а не id записи из EDIZM. И никакого id в таблице EDIZM не держим вообще. Что это дает: проще писать запросы, а не постоянно объединять кучу таблиц; расход дискового пространства не сильно увиличится, потому что во-первых varchar(6) (не надо позволять писать в это поле трактаты varchar(40)) занимает не намного больше места, чем int, во-вторых - избавились от поля id в справочнике. Что в этом плохого: в обход приложения можно занести в поле 'единицы измерения товара' таблицы MD значение, которого нет в справочнике; >> Прочитал про ФИФО. Кажется это не мой случай. Думаю решить задачу отгрузкой в первую очередь партий, в которых критичны сроки годности. Это верно, только если в техническом задании написано, что необходимо отгружать ориентируясь на срок годности. Потому что все равно отгружать будут люди, а не программа и девять раз их действия будут совпадать с алгоритмом программы, а на десятый завскладом не будет на месте и грузчики возьмут то, что просто стоит ближе к выходу. В конце концов все равно какие-то несоответствия между "в компьютере" и "на складе" будут. Для этого собственно инвентаризацию и придумали. Так что, если строгого условия как списывать нет - делайте как вам удобнее. Например по ФИФО. 6. Последнее. Сейчас разбираюся со списанием и формированием расходных накладных. Это вообще самое интересное. Де в том, что в реальности часто производят списание в минус. Происходит это так: есть 50 шт. по цене 5.50 списали 40(но не увезли, то-есть есть на складе, а в базе уже нет) списали 30 (и списали и увезли, ну очень срочно надо было) осток == -20 закупили еще 100 шт. по цене 5.60 физически увезли со склада ранее списаные 40. остаток == 80 То-есть как бы в итоге все нормально. Минусовая отгрузка была компенсирована новым поступлением. А вот теперь скжите - по какой цене находились на складе вот эти -20 шт. ? По 5.50, а компенсировались по 5.60 80*5.60 - (100*5.60 + (-20)*5.50) == -2 недостача Самый простой способ этого избежать - запретить отрицательные остатки, есть и другие способы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2005, 19:42 |
|
||
|
Профессионалы, раскритикуйте модель складской БД для курсовой
|
|||
|---|---|---|---|
|
#18+
Прошу прощения. Не заметил что у вас без цен, только количественные остатки. Это сильно все упрощает. Обычно 'типа группы медикамента'/'группа медикамента' делают в виде дерева. Соответственно одна таблица, ссылающаяся сама на себя, и неограниченное количество уровней вложенности, а не два. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2005, 20:26 |
|
||
|
Профессионалы, раскритикуйте модель складской БД для курсовой
|
|||
|---|---|---|---|
|
#18+
zayacОбычно 'типа группы медикамента'/'группа медикамента' делают в виде дерева. Если я верно понял , речь идет о рекурсивном дереве. Спасибо за совет. А цены действительно формальный атрибут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2005, 20:57 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33207697&tid=1545728]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
136ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
2ms |
| others: | 254ms |
| total: | 494ms |

| 0 / 0 |
