Хелпикс

Главная

Контакты

Случайная статья





Пример 2.



«ИСПОЛНИТЕЛЬ» получил заказ - спроектировать базу данных для «Отдела учета налогообложений». В результате разговоров с сотрудниками «ЗАКАЗЧИКА» он собрал следующую информацию:

О межтабличных связях. Вариант 17. PDF

«ИСПОЛНИТЕЛЬ» предложил такую базу данных (некоторые поля таблиц опущены):

По этой диаграмме проектного описания базы данных ряд замечаний вида уже рассмотренного выше:

¨ Маловероятно, что «Номер декларации» уникален в таблице «Декларации». Если их нумерует налоговая инспекция (НИ), то скорее всего – каждая независимо от других НИ (например от единицы). Если их нумерует сам налогоплательщик, то уникальность совсем невероятна. Видимо надо уточнить это поле первичного ключа таблицы «Декларации» полем «Номер НИ, куда подана декларация», или полем «ИНН (Индивидуальный Налоговый Номер) налогоплательщика, подавшего эту декларацию».

¨ Поле «ИНН налогоплательщика» в таблице «Декларации» должно быть. Иначе, как узнать - кто подал эту декларацию (и описать межтабличную связь с таблицей «Налогоплательщик»).

Аналогичная ситуация для поля «Номер НИ» в этой таблице - как узнать, куда подана эта декларация.

¨ В таблице «Организация» указан первичный ключ «ИНН организации». Да «ИНН организации» действительно однозначно идентифицирует организацию. Но смысл таблицы «Организация» фактически не совсем такой – в ней указано поле «Полученная сумма». Дело в том, что к декларации прикладывается список всех сумм доходов, которые в этот год получал налогоплательщик, с указанием соответствующих организаций, в которых он эти суммы получал.

Именно поэтому в диаграмме (правильно) прорисована связь – один для «Декларации» ко многим для «Организаций». Поскольку налогоплательщик мог получать суммы много раз в разных (и даже одних и тех же) организациях. Именно поэтому в таблице «Организации» хранится «Полученная сумма» вместе с «ИНН организации», в которой эта сумма получена.

Но тогда появляются два вопроса:

§ «ИНН организации» не может быть уникальным ключом в такой таблице – в одной и той же организации многие налогоплательщики могли получать свои суммы дохода, и в строках об этих суммах «ИНН организации» будет повторяться.

§ В таблице «Организации» нет полей-реквизитов, с помощью которых можно было бы разобраться с вопросом – а кому эти организации выплачивали эти суммы. NumberTax, написанный на связи с таблицей «Декларации», отсутствует в таблице «Организации», а потому такая «Организация» на может показать таким полем на «Декларацию», к которой относится эта самая полученная в этой организации сумма.

Кстати для такой таблицы «Организация» в такой базе данных первичный ключ не обязателен, в том смысле, что он не используется для описания межтабличных связей.

 

 

Теперь мы имеем достаточно полное и корректное проектное описание нашей базы данных. Однако не очень хорошо, что в таблице «Организация» сведения об организации будут повторяться в строках каждого налогоплательщика, получавшего доход в этой организации. Это связано с недостаточным уровнем нормализации спроектированной базы данных.

Отделим от таблицы «Организация» информацию о доходах налогоплательщиков:

Теперь таблица «Организация» действительно чиста от посторонней информации, а новая таблица «Доходы» содержит информацию о том: где сколько и кто получил, а точнее – в какой декларации объявлена эта сумма. С такой базой данных у программистов будет заметно меньше проблем по поддержанию согласованности данных в процессе решения задач предметной области.



  

© helpiks.su При использовании или копировании материалов прямая ссылка на сайт обязательна.