powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование без избыточности
63 сообщений из 63, показаны все 3 страниц
Проектирование без избыточности
    #39395637
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте.

Я не могу никак увязать две сущности - действие и документ. На одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении".
Я понимаю, что тут связь "один ко многим", 2 таблицы - "Действия" и "Документы", связанные "один ко многим". Но когда я так делаю, то запросы получаются совершенно безумные по объему и сложности, потому что действий полно, а один документ может висеть на разных действиях. Выглядит ужасно и работает через пень-колоду.

Я решила было плюнуть и вообще не выносить документы в отдельную таблицу, а сделать для ИД документа 2 поля в основных таблицах. Например, в таблице "Действия" 2 поля "document_id". Но меня беспокоит, что это будет типа избыточность или как там ее. Я ненавижу избыточность и стараюсь строить базы строго из нужных полей, а тут получается, что одно поле "document_id" у меня почти всегда будет пустое (очень мало действий, на которых висело бы сразу 2 документа). Но зато запросы меньше и аккуратнее и работают чище.

Посоветуйте что-нибудь, а то я запуталась. Что выбрать? Я хочу сделать по правилам.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395673
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelЗдравствуйте.

Я не могу никак увязать две сущности - действие и документ. На одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении".
Я понимаю, что тут связь "один ко многим", 2 таблицы - "Действия" и "Документы", связанные "один ко многим". Но когда я так делаю, то запросы получаются совершенно безумные по объему и сложности, потому что действий полно, а один документ может висеть на разных действиях. Выглядит ужасно и работает через пень-колоду.

Я решила было плюнуть и вообще не выносить документы в отдельную таблицу, а сделать для ИД документа 2 поля в основных таблицах. Например, в таблице "Действия" 2 поля "document_id". Но меня беспокоит, что это будет типа избыточность или как там ее. Я ненавижу избыточность и стараюсь строить базы строго из нужных полей, а тут получается, что одно поле "document_id" у меня почти всегда будет пустое (очень мало действий, на которых висело бы сразу 2 документа). Но зато запросы меньше и аккуратнее и работают чище.

Посоветуйте что-нибудь, а то я запуталась. Что выбрать? Я хочу сделать по правилам.

Если у Вас на одном действии может быть несколько документов, а один документ относиться к нескольким действиям - это, очевидно, отношение "многие ко многим".
Достаточно странно, что добавление одной связующей таблицы превращает запросы в "безумные"
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395679
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин, спасибо за ответ.
Понимаете, на самом деле получается гораздо больше таблиц в запросе! Вовсе не две!
1. Таблица "Действия".
2. Таблица "Ассоциированные документы", где действиям присвоены ид документов.
3. Таблица "Документы" с полями серии, номера, даты начала и окончания, выдавшей организации, подписавшего человека.
4. Таблица "Юрлица", связанная с таблицей "Документы" по ид_юрлица" - для получения в запросе наименования юрлица, выдавшего документ.
5. Таблица "Физлица", связанная с таблицей "Документы" по ид_физлица" - для получения в запросе наименования физлица, подписавшего документ.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395685
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelКот Матроскин, спасибо за ответ.
Понимаете, на самом деле получается гораздо больше таблиц в запросе! Вовсе не две!

Это понятно, я имел в виду -становится на одну таблицу больше.
В одном случае у Вас 4 таблицы, в другом 5 - такая ли большая разница?
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395733
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении".Если документов может быть только два и никогда три или больше (даже в военное время и по особому распоряжению) то ваш подход с двумя document_id вполне нормальный.
Повесьте check на таблицу, чтобы исключить ситауации когда основной document_id пустой, а дополнительный нет.
Добавление третьего document_id превращает check в очень громоздкий, а четвертый в полный кошмар.

OkeTurel Я ненавижу избыточность и стараюсь строить базы строго из нужных полейЭто пройдет с годами
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395767
аля1ц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
OkeTurel,

... Я хочу сделать по правилам.


...правила на то и существуют чтоб их нарушать....)


избыточность - если не безумная

может быть полезна



.OkeTure..Я решила было плюнуть
и вообще не выносить документы в отдельную таблицу,
а сделать для ИД документа 2 поля в основных таблицах....


так можно и в уважаемый Ексель вернуться...))
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395790
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelКот Матроскин, спасибо за ответ.
Понимаете, на самом деле получается гораздо больше таблиц в запросе! Вовсе не две!
1. Таблица "Действия".
2. Таблица "Ассоциированные документы", где действиям присвоены ид документов.
3. Таблица "Документы" с полями серии, номера, даты начала и окончания, выдавшей организации, подписавшего человека.
4. Таблица "Юрлица", связанная с таблицей "Документы" по ид_юрлица" - для получения в запросе наименования юрлица, выдавшего документ.
5. Таблица "Физлица", связанная с таблицей "Документы" по ид_физлица" - для получения в запросе наименования физлица, подписавшего документ.
И что с этими таблицами не так? Вполне нормальная структура.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395800
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelНа одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении"
В этом месте у меня зарождается сомнение. Не буду выдавать всю цепочку размышлений, просто скажу результат: имхо, весь этот механизм в итоге приходит к примерно следующему дереву:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Вышестоящий приказ о присвоении
|
+-- Приказ о присвоении сотрудникам первой категории
|   |
|   +-- Присвоение категории Иванову
|   |
|   +-- Присвоение категории Петрову
|
+-- Приказ о присвоении сотрудникам второй категории
    |
    +-- Присвоение категории Сидорову
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395846
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerOkeTurelНа одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении"
В этом месте у меня зарождается сомнение. Не буду выдавать всю цепочку размышлений, просто скажу результат: имхо, весь этот механизм в итоге приходит к примерно следующему дереву:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Вышестоящий приказ о присвоении
|
+-- Приказ о присвоении сотрудникам первой категории
|   |
|   +-- Присвоение категории Иванову
|   |
|   +-- Присвоение категории Петрову
|
+-- Приказ о присвоении сотрудникам второй категории
    |
    +-- Присвоение категории Сидорову

Вот мне тоже кажется, что у действия есть основание и это один документ, а у последнего в свою очередь своё основание.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395923
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelЯ не могу никак увязать две сущности - действие и документ.
OkeTurelПосоветуйте что-нибудь, а то я запуталась. Что выбрать? Я хочу сделать по правилам.

К черту все правила... - всего и будет две таблицы (не учитывая прочей мишуры типа дат и подписей), только нужно поставить все с головы на ноги - документ первичен, действия по нему вторичны...

- Все документы (и "Вышестоящие" и " Наши" в одной ГЛАВНОЙ таблице docs )
- Если документ "Вышестоящий" (выше уже не бывает), то значение owner (владелец) у него равно нулю (или null, кому как, но мне лучше ноль - ибо это конкретная величина) и соответственно, действий по нему В ПОДЧИНЕННОЙ таблице Actions может и не быть (а могут и быть).
- Если документ " Наш", то значение owner у него содержит id_doc "Вышестоящего" документа из этой же таблицы Docs и соответственно в подчиненной таблице Actions есть вся движуха по этому документу...
Преимущества:
- Документов с owner = 0 "Вышестоящих" будет мало (по вашим же словам) и вы в запросах будете оперировать только с теми документами у которых owner > 0 с "Вашими" документами.
- Не ограниченный уровень иерархии подчинения документов (например, сначала был приказ, потом директива со ссылкой на приказ, а потом уже внутренний приказ со ссылкой на директиву и естественно уже и действиями в Actions).
- при желании "Вышестоящие" документы можно упаковывать и хранить как "Наши", например описывая в Actions их краткое содержание, суть и т.д.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395924
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag- Не ограниченный уровень иерархии подчинения документов (например, сначала был приказ, потом директива со ссылкой на приказ, а потом уже внутренний приказ со ссылкой на директиву и естественно уже и действиями в Actions).

Если такое будет, то в таблицу Docs добавить дополнительный признак наш/не наш дабы отделить мух от котлет...
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395929
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в общем имхо окончательный вариант таки с признаком наш/не наш (my) на случай если иерархия документов больше двух или если вообще нет "вышестоящих" документов, а только "наш", тогда признаки в записях ставим по ситуации:
1. Вышестоящий документ верхнего уровня:
owner = 0
my = False (не "наш")
2. Вышестоящий документ промежуточный или нижнего уровня:
owner = id_doc вышестоящего
my = False (не "наш")
3. Наш документ имеющий Вышестоящий документ:
owner = id_doc вышестоящего
my = True ("наш")
4. Наш документ не имеющий Вышестоящего документа (сам по себе):
owner = 0
my = True ("наш")
Естественно основная работа теперь будет по признаку my = True ("наш")
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396086
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag,
Может быть ситуация, что с одним действием связаны несколько документов. А эти документы при этом не связаны между собой по типу главный / подчиненный. Например, есть приказ о присвоении категории, а есть к примеру медицинская справка об обследовании, которое должно выполняться при смене категории. То есть к одному действию надо присоединить два документа. Так что без дополнительной таблицы связи многие ко многим не обойтись.

Да и связи между документами могут быть не такими однозначным. Например, есть приказ вышестоящей организации о присвоении категории тем, кто прошел тесты. И есть протокол проведения тестирования сотрудников. И у приказа о присвоении категории будет два вышестоящих документа - вышестоящий приказ и протокол тестирования. А это еще одна таблица связей. :)
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396090
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot Но когда я так делаю, то запросы получаются совершенно безумные по объему и сложности, потому что действий полно, а один документ может висеть на разных действиях. Выглядит ужасно и работает через пень-колоду.


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

(очень мало действий, на которых висело бы сразу 2 документа). Но зато запросы меньше и аккуратнее и работают чище.

не бывает "2".
Либо один, либо больше одного - т. е . много.


я думаю, тебе не надо паниковать, а надо делать как задумано по ТЗ, т. е. про первому варианту, одно действие - много документов.

база данных не должна быть удобной для запросов, она должна быть адекватна по структуре своей задаче.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396093
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelКот Матроскин, спасибо за ответ.
Понимаете, на самом деле получается гораздо больше таблиц в запросе! Вовсе не две!
1.

назови цифру, от которой ты бы считала, что в запросе много таблиц.
потом я назову свою.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396098
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel,

вообще, покажи свою структуру уже... начальный или оба варианта
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396144
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivназови цифру, от которой ты бы считала, что в запросе много таблиц.
потом я назову свою.

Точно, давайте меряться количеством таблиц!

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
  FROM [Analysis].[Track Entry] as track
	
	inner join [Analysis].[Track] as track_id
		  on track.[Track ID] = track_id.[Track ID]

    inner join [Analysis].[Track Calculate - ILE]  as ile_step0 
		  on track_id.[First Step Item Ledger Entry No] = ile_step0.[Entry No_]
		  and track_id.[First Step Company ID] = ile_step0.[Company ID]

    inner join [Analysis].[Track Calculate - ILE]  as ile
		  on track.[Item Ledger Entry No] = ile.[Entry No_]
		  and track.[Item Ledger Company ID] = ile.[Company ID]

	left join 
		(select 
		ile.[Company ID]
		,ile.[Entry No_] as [Item Ledger Entry No]
		,min(ve.[Entry No_]) as [Min Value Entry No]
		from [Analysis].[Track Calculate - ILE]  as ile

			inner join [Analysis].[Track Calculate - VE] as ve
				  on ve.[Item Ledger Entry No_] = ile.[Entry No_]
				  and ve.[Company ID] = ile.[Company ID]

		group by
		ile.[Company ID]
		,ile.[Entry No_]) as next_ile_min_ve
		on next_ile_min_ve.[Company ID] = track.[Next Item Ledger Company ID]
		and next_ile_min_ve.[Item Ledger Entry No] = track.[Next Item Ledger Entry No]
		  
    inner join [Analysis].[Track Calculate - VE] as ve
		  on ve.[Item Ledger Entry No_] = ile.[Entry No_]
		  and ve.[Company ID] = ile.[Company ID]
		  and 
				(  
					 (  
					   (ve.[Item Ledger Entry Type] = 0 or ve.[Entry Type] = 2)
                        and not (ile.[Entry Type] = 0 and ile.Positive = 0 and ve.[Cost Amount (Non-Invtbl_)] = 0)
					  )
					or (ile.[Entry Type] = 2 and ve.Adjustment = 0)
					or ve.[Item Ledger Entry Quantity] <> 0
					or ve.[Entry Type] = 2
					or (ve.[Item Ledger Entry Type] = 1 and ve.[Expected Cost] = 0)
				)
--------revaluation / no revaluation
----- MSDN Nav Design Details: Revaluation
----- Determining if an Inventory Decrease Is Affected by Revaluation
		  and 
			  (
			  	     (ve.[Entry Type] <> 1
				   --or ve.[Valued Quantity] = ile.Quantity --in database we have mistakes with [Valued Quantity]
                   --or ve_next_ile.[Entry No_] is null 
				   or track.[Next Item Ledger Entry No] = 0
				   --or track.[Item Ledger Entry Quantity] = -1 * track.[Next Item Application Entry Quantity]
				   or (ve.[Entry Type] = 1 and ve.[Partial Revaluation] = 0)	
				   )
			   or
			    (ve.[Company ID] = next_ile_min_ve.[Company ID]
				and
			      (not (next_ile_min_ve.[Min Value Entry No] < ve.[Entry No_]
				        and track.[Next Item Ledger Entry Posting Date] <= ve.[Valuation Date] )
				  )
                 )
			   )
------------------------------------
	inner join [Analysis].[Item] as item
		  on ile.[Item No_] = item.No_

	inner join [Analysis].[Location] as location
		  on ile.[Location Code] = location.Code

    left join [Analysis].[Track Calculate - ILE]  as ile_prev
		  on track.[Previous Item Ledger Entry No] = ile_prev.[Entry No_]
		  and track.[Previous Item Ledger Company ID] = ile_prev.[Company ID]

    left join [Analysis].[Purch_ Rcpt_ Line] as rcpt_line
		  on ile_step0.[Document Type] = 5
		  and ile_step0.[Document No_] = rcpt_line.[Document No_]
		  and ile_step0.[Document Line No_] = rcpt_line.[Line No_]
		  AND ile_step0.[Company ID] = rcpt_line.[Company ID]

    left join [Analysis].[Sales Shipment Line] as ship_line
		  on ile.[Document Type] = 1
		  and ile.[Document No_] = ship_line.[Document No_]
		  and ile.[Document Line No_] = ship_line.[Line No_]
		  AND ile.[Company ID] = ship_line.[Company ID]

    left join [Analysis].[Sales Shipment Line] as ship_line_prev
		  on ile_prev.[Document Type] = 1
		  and ile_prev.[Document No_] = ship_line_prev.[Document No_]
		  and ile_prev.[Document Line No_] = ship_line_prev.[Line No_]
		  AND ile_prev.[Company ID] = ship_line_prev.[Company ID]

    left join [Analysis].[Sales Invoice Line] as sal_inv_line
		  on ve.[Document Type] = 2
		  and ve.[Document No_] = sal_inv_line.[Document No_]
		  and ve.[Document Line No_] = sal_inv_line.[Line No_]
		  AND ve.[Company ID] = sal_inv_line.[Company ID]

    left join [Analysis].[Sales Cr_Memo Line] as sal_crm_line
		  on ve.[Document Type] = 4
		  and ve.[Document No_] = sal_crm_line.[Document No_]
		  and ve.[Document Line No_] = sal_crm_line.[Line No_]
		  AND ve.[Company ID] = sal_crm_line.[Company ID]


	left join 
		(select    [Item No_]
					,[code]
					,[Qty_ per Unit of Measure] 
		from [Analysis].[Item Unit of Measure]
		where [code] = 'MT') as uom_mt
	      on uom_mt.[Item No_] = ile.[Item No_]

	left join [Analysis].[Operation Entry (Table)] as old_operation
	on old_operation.[Track ID] = track.[Track ID]
	and old_operation.[Value Entry No] = ve.[Entry No_]
	and old_operation.[Item Ledger Company ID] = track.[Item Ledger Company ID]
	and old_operation.[Item Ledger Entry No] = track.[Item Ledger Entry No]


	where old_operation.[Track ID] is null
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396171
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovvmag,
Может быть ситуация, что с одним действием связаны несколько документов. А эти документы при этом не связаны между собой по типу главный / подчиненный. Например, есть приказ о присвоении категории, а есть к примеру медицинская справка об обследовании,

ИМХО вы собрали в кучу не собираемое (приказ о присвоении очередного воинского звания со справкой в бассейн)...
в Docs руководящие документы, а если нудны подтверждающие документы (иногда), то проще завести дополнительную таблицу для этого и повесить её уже на таблицу Actions как подчиненную...
Но даже в той прошлой моей последней схеме ваша проблема решается на ура добавлением еще одного признака в таблицу Docs - статус документа (например 1 это руководящий, 2 - сопутствующий)
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396323
Фотография ПЕНСИОНЕРКА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelЯ не могу никак увязать две сущности - действие и документ. На одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении".

я бы сочла, что это типа ежедневника или контроля исполнения документов
номерном для ссылки на вышестояший автордатаназваниеисполнительдата исполнение статус10директор10/01/2017наградить женщин к 8 мартапрофком20/02/2017110директор02/03/2017выдать женщинам по хххх руббухгалтерия06/03/201720директор11/01/2017наградить участников вовсовет ветеранов10/02/2017вып120директор22/02/2017выдать ветеранам по хххх руббухгалтерия23/02/201731профком12/01/2017запрос в отдел кадров на работающих женщин старше 30 летотдел кадров14/01/2017вып41профком14/01/2017роздать цехам спискисеменова15/01/2017вып51профком18/01/2017получить спискисеменова20/01/201762совет ветеранов19/01/2017запрос в отдел кадров на работающих ветерановотдел кадров20/01/2017вып72совет ветеранов20/01/2017составить и выверить списки пенсионеров-ветерановильина22/01/2017вып82совет ветеранов25/01/2017оформить ответ в дирекциюильина26/01/2017вып
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396450
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте. :^)

Сейчас прочту все посты и все уясню, а пока только уяснила, что требуется показать мою структуру. Вот моя структура, пожалуйста.

[img] http://savepic.net/8882997.jpg [/img]
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396483
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelЗдравствуйте. :^)

Сейчас прочту все посты и все уясню, а пока только уяснила, что требуется показать мою структуру. Вот моя структура, пожалуйста.

[img] http://savepic.net/8882997.jpg [/img]
Для начала требуется вашу структуру немного упорядочить, чтобы связи через весь экран не проходили...
Вы сами вашу структуру в таком виде понимаете?
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396515
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добавлю, что у меня кадровая база, т.к. я кадровик, а специализированных кадровых систем типа 1-С или Паруса у нас нет. Приходится пыхтеть самой. :)

Уважаемые ответившие, у меня в таблице "Документы" ЕСТЬ 2 поля document_id и document1_id, и второе поле как раз для наддокумента. Я им пользовалась для допсоглашений к трудовым договорам: трудовой договор - наддокумент для допсоглашения, другими словами - допсоглашение подчинено трудовому договору. Но в случае с приказами я не пользовалась этим, а теперь поняла, что да, вышестоящий областной приказ - наддокумент для нашего внутреннего приказа. Когда я вставила эту связь, то запрос заработал более-менее сносно.
Хотя я согласна с s_ustinov, могут быть и два несвязанных между собой документа, висящие на одном действии. Тогда запрос выдает на одного сотрудника 2 строки. А это нельзя, потому что из запроса все экспортируется программно в Эксель в бланк приказа. Но с другой стороны, действительно можно добавить дополнительные свойства документам, типа "руководящий", "сопутствующий", как советует vmag. И в запросе отсеять только нашей организации документы. А с третьей стороны, можно предельно "раздробить" действия, сделать их очень мелкими, и тогда, наверно, будет одно действие - один документ, как и пишет skyANA.

SERG1257, я сейчас попробовала без этого, но если будет продолжаться с моей базой такая петрушка, то придётся. Устала разбираться в собственных запросах. :)

MasterZiv, у меня в одном запросе 9 таблиц, из этих таблиц 6 штук - на самом деле не таблицы, а другие запросы, которые сами состоят из таблиц числом от четырех до семи. Можно ли это считать нормальным?

аля1ц, я не хочу в Эксель, мне он не нравится. )

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

ПЕНСИОНЕРКА, да, похоже на мою таблицу "документы".

Большое спасибо, что ответили мне. :)
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396518
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov, как это упорядочить структуру, там структура нелинейная, не типа "ступенька - другая ступенька", а все перемешано. Все равно будут косые линии.
Если приглядеться, то понимаю. )
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396525
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurels_ustinov, как это упорядочить структуру, там структура нелинейная, не типа "ступенька - другая ступенька", а все перемешано. Все равно будут косые линии.
Если приглядеться, то понимаю. )
Речь не о косых линиях.
При проектировании БД стараются таблицы располагать группами. И чтобы большая часть связей была внутри групп, а между группами было 1-2 связи, а не паутина.
У вас вроде так не получается, так как много "петель". Скорее всего, надо повысить уровень нормализации.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396535
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer, это все так красиво выглядит, как Вы начертили, а на деле не знаю даже, на каждой таблице куча других - кто подписал документ, какая организация издала, если трудовой договор - то на какой основании действует подписавший. Возможно, надо избавиться от некоторой информации, хотя и жалко.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396541
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel,
Например таблицы

persons
accounts
operations
documents_associates

образуют "кольцо". Это явный признак избыточности данных (денормализованная база). У вас явно не те объемы данных, чтобы денормализация была оправданной. Поэтому на вашем месте я бы попробовал для начала привести всё к третьей форме, а уже после этого продумывать, как связывать действия и документы.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396545
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov, я не знаю, захотите ли Вы смотреть мою базу, если я ее приложу, но я уверяю Вас - моя база в смысле нормализации хорошая! У меня ни оно значение не вводится дважды, как и пишут в книгах про базы. И ни одно значение не вводится, если его можно рассчитать (ну, типа стажа - он считается программно). Как и пишут в книгах про базы, у меня таблицы приведены к этим пресловутым нормальным формам. Ну, по крайней мере, я старалась.
Хорошо, я дома постараюсь поаккуратней расположить на экране таблицы и сделаю скрин снова.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396547
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov, если Вы так считаете, что там кольцо, то тогда я подумаю. Возможно, я чего-то не учла.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396552
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurels_ustinov, я не знаю, захотите ли Вы смотреть мою базу, если я ее приложу, но я уверяю Вас - моя база в смысле нормализации хорошая!

А тот рисунок, что вы выложили - не ваша база?
Я говорил про базу на рисунке - она довольно сильно денормализована.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396561
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov, проклятие, я не знала не про какие кольца! Но я поняла - располагать группами, связывать в группах, а связь групп - только в малых дозах. Посмотрю. Мне всегда казалось, что надо одну тему располагать в одной таблице, скажем "награждения", "звания", "лицевые счета", "табельные номера", "наказания", "отпуска" и т.д., у меня так сделано, и все это висит на персон_ид, ну, на человеке то есть... На аккаунт_ид висят операции.
Думаю, кольцо из-за сборной таблицы "ассоциированные документы", где каждому документу ставятся в соответствие или отпуск, или звание, или наказание, или персона. Не делать же много таблиц "документы", где каждому документу только одно что-то соответствует, типа "документ званий", "документы отпусков". Так разве правильно. Таблиц будет уйма.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396568
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurels_ustinov, проклятие, я не знала не про какие кольца! Но я поняла - располагать группами, связывать в группах, а связь групп - только в малых дозах. Посмотрю.

Это не жесткое правило, но так намного удобнее проектировать схему БД.

OkeTurelМне всегда казалось, что надо одну тему располагать в одной таблице, скажем "награждения", "звания", "лицевые счета", "табельные номера", "наказания", "отпуска" и т.д.,
Правильно, это называется "сущность".

OkeTurelДумаю, кольцо из-за сборной таблицы "ассоциированные документы", где каждому документу ставятся в соответствие или отпуск, или звание, или наказание, или персона. Не делать же много таблиц "документы", где каждому документу только одно что-то соответствует, типа "документ званий", "документы отпусков". Так разве правильно. Таблиц будет уйма.
У вас проблема со схемой БД - именно об этом свидетельствуют "кольца". В чем именно... В том виде, в каком схема БД сейчас, разбирать долго. Попробуйте сами упорядочить свою схему - после этого будет понятнее.
А количество таблиц не обязательно станет больше. Скорее всего можно будет обойтись одной универсальной таблицей "документы".
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396577
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelsoftwarer, это все так красиво выглядит, как Вы начертили, а на деле не знаю даже, на каждой таблице куча других
О том, что я нарисовал, надо думать ещё до таблиц. Надо представить бизнес-процесс в чётких и удобных терминах. А те таблицы, которые Вы называете - это справочники, их может быть сколько угодно, они практически не влияют на сложность запроса.

s_ustinovобразуют "кольцо". Это явный признак избыточности данных (денормализованная база).
Хм. Имхо, недостаточно обоснованное утверждение, назовём так. Прямо таки хочется спросить, как избавиться от избыточности данных и нормализовать следующую базу:

Код: plaintext
1.
2.
3.
4.
5.
1, Адам, null
2, Каин, 1
3, Авель, 1
4, Енох, 2
5, Ирад, 4
....

s_ustinovУ вас проблема со схемой БД - именно об этом свидетельствуют "кольца"
Хм.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396627
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerХм. Имхо, недостаточно обоснованное утверждение, назовём так.
https://ru.wikipedia.org/wiki/%D0%A2%D1%80%D0%B5%D1%82%D1%8C%D1%8F_%D0%BD%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%84%D0%BE%D1%80%D0%BC%D0%B0]Запоминающееся и, по традиции, наглядное резюме определения 3NF Кодда было дано Биллом Кентом: каждый неключевой атрибут «должен предоставлять информацию о ключе, полном ключе и ни о чём, кроме ключа »[1].
То есть атрибут должен зависеть только от ключа. Не допускается зависимость одного неключевого атрибута от другого неключевого атрибута.
На картинке в таблице documents_associates атрибут person_id зависит от (однозначно определяется) атрибута operation_id. И при этом operation_id не является первичным ключом documents_associates.
И как раз "петли" и показывают "визуально" наличие таких нарушений.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396637
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovНа картинке в таблице documents_associates атрибут person_id зависит от (однозначно определяется) атрибута operation_id.
Вы так думаете? :) Я вот не вижу оснований для такого утверждения. И даже уверен, что нет никаких проблем построить контрпример.

s_ustinovИ как раз "петли" и показывают "визуально" наличие таких нарушений.
Я Вам чуть выше нарисовал петлю. И жду указаний на избыточные данные и инструкций по денормализации.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396648
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarers_ustinovНа картинке в таблице documents_associates атрибут person_id зависит от (однозначно определяется) атрибута operation_id.
Вы так думаете? :) Я вот не вижу оснований для такого утверждения. И даже уверен, что нет никаких проблем построить контрпример.

Я уверен , так как могу построить запрос, однозначно определяющий person_id для любого operation_id, не используя таблицу documents_associates. А это и есть зависимость одного атрибута от другого.
Любопытно будет посмотреть на контрпример.
softwarers_ustinovИ как раз "петли" и показывают "визуально" наличие таких нарушений.
Я Вам чуть выше нарисовал петлю. И жду указаний на избыточные данные и инструкций по денормализации.
Не очень понятно, где в вашем примере "петля" - вы ведь, насколько понимаю, нарисовали данные из одной таблички.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396688
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelvmag, я долго ломала голову, что первично, мне кажется, что первично действие, возможно я ошибаюсь. Не знаю, в таблице "Документы" можно сделать ссылку на что угодно...

По вашей логике кадровик сидит в курилке курит и вдруг видит дрейфующего по аллее прапорщика Сидорова, который пришпандорил себе на китель майорские погоны... ну да, действие совершено, нужно подрываться и срочно готовить приказ о присвоении прапорщику Сидорову очередное воинское звание майор...
Документ (грубо) состоит из: шапки и тела документа (возьмите за образец что угодно для наглядности например накладную, счет, акт...). В главную таблицу docs пишут шапку (номер, дата документа, ...) а в подчиненную строки этого документа - в вашем случае это подчиненная таблица "действия"... То, что у вас все наоборот (действие первично) говорит о том, что у вас очень разнородные документы вплоть до полной несовместимости, например, как совместить присвоение звания и отпуск (разное количество и назначение атрибутов) ?
Если бы вы сразу сказали, что у вас кадровая задача, я бы вам сразу посоветовал уйти от реляционной БД и посмотреть в сторону БД для хранения документов типа 1С кадры и ей подобных, там именно складируются разнородные документы, на базе которых написаны соответствующие обработки и кстати там такая же структура всех документов - шапка + тело документа... НО ОНИ ВСЕ РАЗНЫЕ ПО СТРУКТУРЕ И В ШАПКЕ И В ТЕЛЕ...
OkeTurelя кадровик, а специализированных кадровых систем типа 1-С или Паруса у нас нет
Остается только посочувствовать...
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396710
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovНе очень понятно, где в вашем примере "петля" - вы ведь, насколько понимаю, нарисовали данные из одной таблички.
Хм. А Вы посмотреть в эти данные не пробовали? Могу ещё написать ddl этой таблицы, если так не очевидно:

Код: sql
1.
2.
3.
4.
5.
6.
create table Men(
  id integer not null,
  name varchar2(240 char) not null,
  parent_id integer,
  constraint Men_pk primary key(id),
  constraint Men_Men_fk foreign key(parent_id) references Men(id));


По-прежнему жду указаний по нормализации этой петли :)

s_ustinovЯ уверен , так как могу построить запрос, однозначно определяющий person_id для любого operation_id, не используя таблицу documents_associates.
А кто Вам сказал, что person_id, лежащий в таблице documents_associates, каким-либо образом зависит от person_id, который Вы можете определить через operation_id? Положите в эту структуру информацию "Иванов выписал живительных пиздюлей Петрову" - вот и будет тот контрпример, который Вы не чаяли увидеть
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396711
аля1ц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vmag,

только хотел пригласить Вас в студию..

))


да чо ждать-то

жисть - покажет


обязательно
обязательно










избыточность
может быть - ОЧЕНЬ полезна

))
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396730
Фотография ПЕНСИОНЕРКА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel,

у вас к таблице persons прицеплено по кону персоны наверное 20 таблиц
без малейшего ущерба для понимания вы можете скрыть эту таблицу(правой мышкой)
---
тогда вы увидите реальную схему ваших остальных таблиц, а не паутину
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396758
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarers_ustinovНе очень понятно, где в вашем примере "петля" - вы ведь, насколько понимаю, нарисовали данные из одной таблички.
Хм. А Вы посмотреть в эти данные не пробовали? Могу ещё написать ddl этой таблицы, если так не очевидно:

Код: sql
1.
2.
3.
4.
5.
6.
create table Men(
  id integer not null,
  name varchar2(240 char) not null,
  parent_id integer,
  constraint Men_pk primary key(id),
  constraint Men_Men_fk foreign key(parent_id) references Men(id));


По-прежнему жду указаний по нормализации этой петли :)

Насколько помню, во "Введении" что то написано о нормализации в таких ситуациях... Будет время, прочитаю - напишу.

softwarers_ustinovЯ уверен , так как могу построить запрос, однозначно определяющий person_id для любого operation_id, не используя таблицу documents_associates.
А кто Вам сказал, что person_id, лежащий в таблице documents_associates, каким-либо образом зависит от person_id, который Вы можете определить через operation_id? Положите в эту структуру информацию "Иванов выписал живительных пиздюлей Петрову" - вот и будет тот контрпример, который Вы не чаяли увидеть
Я исхожу из того, что имена атрибутам выдаются все же осмысленно. Например, чуть выше используются названия "id" и "parent_id"
В нормальных базах для записи информации типа "Иванов выписал живительных пиздюлей Петрову" используются поля с названиями "ID выписывающего пиздюли" и "ID получающего пиздюли".
Я все таки верю в людей... Возможно, зря...
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396772
аля1ц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ПЕНСИОНЕРКАOkeTurel,

у вас к таблице persons прицеплено по кону персоны наверное 20 таблиц
без малейшего ущерба для понимания вы можете скрыть эту таблицу(правой мышкой)
---
тогда вы увидите реальную схему ваших остальных таблиц, а не паутинусхема - в Мозгу
и
из Мозга..

и тд

лична
не нужны бумазьки, карандаши и авторучки



правильно
Уровень - Чуйки





с Уважением к ВАМ
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396775
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovВ нормальных базах для записи информации типа "Иванов выписал живительных пиздюлей Петрову" используются поля с названиями "ID выписывающего пиздюли" и "ID получающего пиздюли".

А длчя записи информации "Иванов подарил цветочки Петрову" - в этих нормальных базах делают отдельную таблицу с отдельными атрибутами? А для "Петров ответил Иванову на форуме" - третью?
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396796
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскинs_ustinovВ нормальных базах для записи информации типа "Иванов выписал живительных пиздюлей Петрову" используются поля с названиями "ID выписывающего пиздюли" и "ID получающего пиздюли".

А длчя записи информации "Иванов подарил цветочки Петрову" - в этих нормальных базах делают отдельную таблицу с отдельными атрибутами? А для "Петров ответил Иванову на форуме" - третью?
Неееее...
Для таких задач создают ОДНУ таблицу:

CREATE TABLE actions (
[id_action] [int] IDENTITY(1,1) NOT NULL,
[Что Дулин сделал для Михалыча] [nvarchar](max)
);

А потом заносят в неё мега ценную информацию:
INSERT INTO actions
([Что Дулин сделал для Михалыча])
VALUES
('Подарил очень красивую красную розу');

или

INSERT INTO actions
([Что Дулин сделал для Михалыча])
VALUES
('Признался в неземной любви');
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396802
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovКот Матроскинпропущено...

А длчя записи информации "Иванов подарил цветочки Петрову" - в этих нормальных базах делают отдельную таблицу с отдельными атрибутами? А для "Петров ответил Иванову на форуме" - третью?
Неееее...
Для таких задач создают ОДНУ таблицу:



Для каких "таких"?
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396810
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскинs_ustinovпропущено...

Неееее...
Для таких задач создают ОДНУ таблицу:



Для каких "таких"?

Для таких:
Кот МатроскинА длчя записи информации "Иванов подарил цветочки Петрову"
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396823
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov,

Т.е. Вы все верите, верите в людей, рассчитываете что они будут только морды друг другу бить, и тут раз - кто-то кому-то дарит цветочки. И все, базу на выброс? Непрактично как-то :)
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396846
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин,
Не так всё было. :))
Я верю в людей, верю в то, что дети сегодня заснут пораньше... И тут бац! Предлагают хранить в базе информацию "Иванов подарил цветочки Петрову"... Ну вот как так можно?
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396968
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag, я вчера вечером подумала и теперь согласна с Вами. Я переделаю базу "от документа", т.е. первичным будет документ, пляшем от документа, на нем висят дейтсвия. Кстати, по-моему и в Парусе сделано "от документа".
Спасибо за совет.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396973
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ПЕНСИОНЕРКА, совершенно верно, у меня на персон_ид висят образование, аттестация, семейное положение, больничные, контроль флюорографии и санминимума, ассоциированные персоны (мамы-папы), наказания и награждения.
Да, скрыла, стало понятней. Спасибо.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39397051
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer, все в общих чертах понятно, и я решила вообще уйти от реаляционной модели и сделать как в 1-С, как мне советовал vmag. У меня получалась реляция, потому что я придавала большое значение таблице "персоны" и считала ее главной и думала - надо, чтобы на ней все висело. Думаю, надо сделать "Персоны" простым справочником, который, может, и связан-то ни с чем не будет, ну, будет ИД, но этот ИД в таком большом количестве документов будет (как шапок документов, так и табличной части), что нет смысла там связи будет делать.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39397263
аля1ц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
OkeTurelsoftwarer, все в общих чертах понятно, и я решила вообще уйти от реаляционной модели и сделать как в 1-С, как мне советовал vmag. У меня получалась реляция, потому что я придавала большое значение таблице "персоны" и считала ее главной и думала - надо, чтобы на ней все висело.

Думаю, надо сделать "Персоны" простым справочником,

который, может, и связан-то ни с чем не будет,

ну, будет ИД,
но этот ИД в таком большом количестве
документов будет (как шапок документов, так и табличной части),
что нет смысла там связи будет делать.

ну вроде - Умница


почти

..;))
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39398662
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelЗдравствуйте.

Я не могу никак увязать две сущности - действие и документ. На одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении".
Я понимаю, что тут связь "один ко многим", 2 таблицы - "Действия" и "Документы", связанные "один ко многим". Но когда я так делаю, то запросы получаются совершенно безумные по объему и сложности, потому что действий полно, а один документ может висеть на разных действиях. Выглядит ужасно и работает через пень-колоду.

Я решила было плюнуть и вообще не выносить документы в отдельную таблицу, а сделать для ИД документа 2 поля в основных таблицах. Например, в таблице "Действия" 2 поля "document_id". Но меня беспокоит, что это будет типа избыточность или как там ее. Я ненавижу избыточность и стараюсь строить базы строго из нужных полей, а тут получается, что одно поле "document_id" у меня почти всегда будет пустое (очень мало действий, на которых висело бы сразу 2 документа). Но зато запросы меньше и аккуратнее и работают чище.

Посоветуйте что-нибудь, а то я запуталась. Что выбрать? Я хочу сделать по правилам.
Здравствуйте.
Чтобы "сделать по правилам" нужно знать теорию и практику проектирования баз данных на таком уровне, на котором Вы не будете нуждаться в советах)) Сейчас Вам полезны большинство советов, то есть, советы для Вас совершенно бесполезны. У Вас сейчас - не имеющая никакого смысла схема БД, которую советы могут сделать только еще более бессмысленной. Если Вы, действительно, хотите тратить свою жизнь на изучение теории и практики проектирования баз данных, то (с учетом того, что у Вас есть и какая-то основная работа, насколько я понимаю) у Вас уйдет от трех до пяти лет, чтобы сделать хороший техпроект в этой предметной области. Собственно первые же два-три месяца и Вам самой покажут - интересно ли Вам, на самом деле, это занятие)) Начните со словаря. И с какого-нибудь относительно сложного понятия, например, "документ".
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39402365
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте.

Я переделала базу, вот моя новая схема.
http://hostingkartinok.com/show-image.php?id=5d241fdb6c770eb5599549021e9032c2

Все висит на таблице "Документы".
База стала намного удобнее. Большинство запросов оказались не нужны. Оставшиеся срабатывают без ошибок.
В коде тоже многое стало не нужно, и формы почти все вообще перестали нуждаться в модулях.
Макросы, скорее всего, многие тоже отправятся в топку.
Общий вес базы сократился примерно в 2 раза без потери функциональности.

Спасибо большое за прекрасные советы!
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39402401
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel
Да, сейчас намного красивее :)
Попробуйте еще person_id перенести в таблицу "Документы" (убрав из остальных таблиц). Ведь это поле есть во всех документах. И подумать о переносе других "общих" полей, которые есть во всех (или большинстве) документах. И вам намного проще будет строить запрос "Получить все документы по Васе Пупкину".
То есть ваша база будет содержать ОДНУ основную таблицу "документы", в которую заносятся основные данные по документу - сотрудник, тип документа, номер документа (дата документа и еще несколько полей, которые есть во всех или почти всех документах). И будет еще два основных справочника - сотрудники и типы документов.
И таблицы - расшифровки для каждого типа документов, где они требуются. Некоторые типы документов могут содержать только общие поля, уже содержащиеся в основной таблице "Документы", и не требовать отдельной таблицы для дополнительных, специфичных только для этого типа документов, полей.

Сейчас, чтобы найти список всех документов по сотруднику, вам надо включить в запрос таблицы для всех возможных типов документов. И если добавите новый тип документов - надо будет переделывать этот запрос (добавлять новую таблицу).
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39402720
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel,

ну из всех минусов теперь явных только два и то спорных:
- необходима доработка структуры и возможно интерфейса при добавлении нового типа документов... прямо как у фирмы 1С...
- из-за простоты схемы, вместо вас для доработок и развития теперь могут взять какого-то пионэра...
берегите исходники...
зато есть плюсы и они гораздо весомее:
- теперь вам всё понятно, прозрачно и спокойнее на душе...
- ничего не глючит и работает быстрее...
- вы становитесь востребованной (пока) с точки зрения развития и доработки программы...
- Ой... а с технической точки зрения сколько плюсов... только одна мысль о том, что строки каждого документа можно хранить в отдельном хранилище сразу решает кучу проблем: с архивацией, доступом,
объемами документов, переходом на новый год и т.д.
имхо ваша модель теперь таки имеет шансы...
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39403412
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет! :о)

s_ustinov, но у меня в базе документ может относиться к одному сотруднику (типа паспорт или пенсионное) и к нескольким сразу (например, на приказе о приеме на работу может висеть несколько сотрудников, один документ - несколько людей). И во втором случае вставлять person_id в таблицу "Документы", наверно, не надо? Или тогда придется дублировать документы, скажем, один приказ занести 2 раза, на Иванова и тот же самый на Петрова.

vmag, я не против дорабатывать структуру... Сейчас вот 54 типа документа в таблице "Категории документов", будут еще - доработаю (табличка для табличной части, формочка для ввода в табличную часть, если надо - запросик для вывода в Ворд или Эксель).

Да, я вздохнула спокойно по сравнению с теми временами, когда считала, что реляционная база - это круто.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39403490
buven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelИ во втором случае вставлять person_id в таблицу "Документы", наверно, не надо? Или тогда придется дублировать документы, скажем, один приказ занести 2 раза, на Иванова и тот же самый на Петрова.

А вот здесь я бы пошел к тому, кто подписывает, и слезно попросил подписывать приказы на каждого отдельно:)
Приказы же формируются на основании заявления о приеме, которое, в свою очередь, ни разу не коллективное.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39403689
Фотография ПЕНСИОНЕРКА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
buvenПриказы же формируются на основании заявления о приеме, которое, в свою очередь, ни разу не коллективное.

бригаду ремонтников в 20 человек посылают в командировку --печатаем 20 приказов
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39403707
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ПЕНСИОНЕРКАbuvenПриказы же формируются на основании заявления о приеме, которое, в свою очередь, ни разу не коллективное.

бригаду ремонтников в 20 человек посылают в командировку --печатаем 20 приказов
Решили всем сотрудникам проиндексировать зарплату - делаем приказ на каждого из тысячи сотрудников. И все это потому что программист не очень понимает отношение M:N :)
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39403714
buven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинПЕНСИОНЕРКАпропущено...


бригаду ремонтников в 20 человек посылают в командировку --печатаем 20 приказов
Решили всем сотрудникам проиндексировать зарплату - делаем приказ на каждого из тысячи сотрудников. И все это потому что программист не очень понимает отношение M:N :)
Приказ будет один, доп. соглашений к ТД будет 1000 :)
Я в кадрах не силен, поэтому, наверно, не совсем корректно выразился. Посыл был в том, что некоторые процессы можно и нужно "выпрямлять" на уровне регламентов, и довольно часто их кривость видна именно при попытке автоматизации бардака:)
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39404229
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel
s_ustinov, но у меня в базе документ может относиться к одному сотруднику (типа паспорт или пенсионное) и к нескольким сразу (например, на приказе о приеме на работу может висеть несколько сотрудников, один документ - несколько людей). И во втором случае вставлять person_id в таблицу "Документы", наверно, не надо? Или тогда придется дублировать документы, скажем, один приказ занести 2 раза, на Иванова и тот же самый на Петрова.

Сейчас в базе у вас один номер документа (одна строка) и несколько строк в таблице конкретного вида документа (один ко многим)?
Можно оставить существующую схему, но лично я бы добавил таблицу "Детали документа" со связью много к одному с таблицей "Документы", где и указывал бы сотрудника. И тогда уже к этой таблице делал уточняющие таблицы.
Сейчас вам надо под каждый новый тип документа создавать новые таблицы, а это не всегда нужно. Очень большое количество таблиц начинает мешать со временем.

OkeTurelДа, я вздохнула спокойно по сравнению с теми временами, когда считала, что реляционная база - это круто.

А какая, по вашему мнению, у вас база сейчас?
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39405420
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovСейчас в базе у вас один номер документа (одна строка) и несколько строк в таблице конкретного вида документа (один ко многим)?Да.
s_ustinovА какая, по вашему мнению, у вас база сейчас? Ну, реляционная, но в меру... ))) Связь всего по id_документа...
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39419005
аля1ц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
OkeTurels_ustinovСейчас в базе у вас один номер документа (одна строка) и несколько строк в таблице конкретного вида документа (один ко многим)?Да.
s_ustinovА какая, по вашему мнению, у вас база сейчас?
Ну, реляционная, но в меру... )))

Связь всего по id_документа...

во-во ----->>> почти Задорнов

но в меру

)))


ач е - этого мало чоль
...
Рейтинг: 0 / 0
63 сообщений из 63, показаны все 3 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование без избыточности
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]