Описание предметной области. В соответствии с положениями Гражданского процессуального кодекса Украины, иск предъявляется в письменной форме путем подачи искового заявления в суд первой

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

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

Исковое заявление должно содержать:
1. Наименование суда, в который подается заявление;
2. Имя (наименование) истца и ответчик (истцом и ответчиком могут быть физические и юридические лица, а также государство), а также имя представителя истца, если исковое заявление подается представителем, их место жительства или местонахождение, почтовый индекс, номер средств связи, если таковой известен;
3. Содержание исковых требований (следует заметить, что в одном исковом заявлении может быть несколько исковых требований, которые связаны между собой);
4. Цену иска относительно требований имущественного характера;
5. Изложение обстоятельств (фактов), которыми истец обосновывает свои требования;
6. Указание доказательств (любые фактические данные, на основании которых суд устанавливает наличие или отсутствие обстоятельств, которые обосновывают требования, а также имеют значение для решения дела), которые подтверждают каждое обстоятельство, наличие оснований для освобождения от доказывания;
7. Перечень документов, которые прибавляются к заявлению.

В результате анализа выделим связи между объектами предметной:

Рисунок 2.1 – Связи между объектами предметной области

 

Исковое заявление подписывается истцом или его представителем с указанием даты его представления.

Исковое заявление должно отвечать другим требованиям, установленным законом.

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

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

Если исковое заявление подается представителем истца, к исковому заявлению прилагается доверенность или другой документ, который подтверждает его полномочия.

Цели проектирования

На сегодняшний день наиболее часто используются три модели данных: иерархическая, сетевая и реляционная. Кроме них существуют и другие модели, например модель данных, основанная на инвертированных списках или объектно-ориентированная, однако они не имеют широкого распространения, так как базы на инвертированных списках использовались на заре развития СУБД, а объектно-ориентированные базы данных ещё не до конца изучены. Таким образом, выбор сокращается до трёх вышеназванных моделей данных.

Рассмотрим более подробно преимущества и недостатки каждой модели представления данных.

Иерархическая модель данных. Организация данных в СУБД иерархического типа определяется в терминах: элемент, агрегат, запись (группа), групповое отношение, база данных.

Атрибут (элемент данных) - наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.

Запись – это именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи - конкретная запись с конкретным значением элементов

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

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

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

Недостатки иерархических БД:

- частично дублируется информация между записями, причем в иерархической модели данных не предусмотрена поддержка соответствия между парными записями;

- иерархическая модель реализует отношение между исходной и дочерней записью по схеме 1:N, то есть одной родительской записи может соответствовать любое число дочерних.

Операции над данными, определенные в иерархической модели:

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

- изменить значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям;

- удалить некоторую запись и все подчиненные ей записи;

- извлечь корневую запись по ключевому значению, извлечь следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева)

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

Сетевая модель данных. Основные принципы сетевой модели данных были разработаны в середине 60-х годов. Сетевая модель данных определяется в тех же терминах, что и иерархическая Сетевой подход к организации данных является расширением иерархического подхода. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных потомок может иметь любое число предков.

Сетевая БД состоит из набора записей и набора связей между ними, а если говорить более точно: из набора экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи.

Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться два условия:

- Каждое экземпляр типа P является предком только в одном экземпляре L;

- Каждый экземпляр C является потомком не более чем в одном экземпляре L.

На формирование типов связи не накладываются особые ограничения; возможны, например, ситуации:

- тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 (как в иерархии).

- данный тип записи P может быть типом записи предка в любом числе типов связи.

- данный тип записи P может быть типом записи потомка в любом числе типов связи.

- может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 - два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться.

- типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком - в другой.

- предок и потомок могут быть одного типа записи.

Примерный набор операций может быть таковым:

- найти конкретную запись в наборе однотипных записей;

- перейти от предка к первому потомку по некоторой связи;

- перейти к следующему потомку в некоторой связи;

- перейти от потомка к предку по некоторой связи;

- создать новую запись;

- уничтожить запись;

- модифицировать запись;

- включить в связь;

- исключить из связи;

- переставить в другую связь и т.д.

К достоинствам сетевой СУБД можно отнести возможность экономии памяти за счет разделения подобъектов. Как и в иерархической модели обеспечивается только поддержание целостности по ссылкам (владелец отношения - член отношения).

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

Преимущества реляционной модели данных:

- каждая таблица состоит из однотипных строк и имеет уникальное имя;

- строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего;

- строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку такой таблицы;

- столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы);

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

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

К числу достоинств реляционного подхода можно отнести:

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

- наличие простого и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных;

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

Относительная простота и эффективность РСУБД, а также наличие солидной теоретической базы сделало эту модель данных наиболее распространённой на сегодняшний день. Абсолютное большинство систем управления базами данных, присутствующих на рынке программного обеспечения основываются именно на реляционной модели.

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

Методы проектирования

Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель "сущность-связь" (entity - relationship model, ER - model).

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

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

Сущность (entity) - это объект, который может быть идентифицирован неким способом, отличающим его от других объектов. Примеры: конкретный человек, предприятие, событие и т.д.

Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами). Примеры: все люди, предприятия, праздники и т.д. Наборы сущностей не обязательно должны быть непересекающимися. Например, сущность, принадлежащая к набору МУЖЧИНЫ, также принадлежит набору ЛЮДИ.

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

Множество значений (область определения) атрибута называется доменом. Например, для атрибута ВОЗРАСТ домен (назовем его ЧИСЛО_ЛЕТ) задается интервалом целых чисел больших нуля, поскольку людей с отрицательным возрастом не бывает.

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

Связь (relationship) - это ассоциация, установленная между несколькими сущностями.

К сожалению, не существует общих правил определения, что считать сущностью, а что связью.

Набор связей (relationship set) - это отношение между n (причем n не меньше 2) сущностями, каждая из которых относится к некоторому набору сущностей.

Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.

Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, СОРТ может быть определен для многих сущностей: ВИНО, МАСЛО, МУКА и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности СОТРУДНИК являются ФИО, ДОЛЖНОСТЬ, ВОЗРАСТ, ОКЛАД и т.д. Здесь также существует различие между типом и экземпляром.

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

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

Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей.

Преимущество ER-диаграмм в том, что они позволяют наглядно представить взаимосвязь объектов предметной области и при этом нет необходимости в манипулировании множеством атрибутов при нормализации, как это имеет место в методе декомпозиции.

Выделение объектов

Анализ предметной области обычно осуществляется:

- на основании существующих сведений о предметной области, в масштабах в которых она должна быть представлена в создаваемой базе данных и работающих с ней приложениях;

- исходя из целей проектирования программной среды;

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

В конечном итоге анализ предметной области должен привести к созданию проекта базы данных.

Вначале необходимо изобразить сущности и связи между ними. Как правило, каждой сущности (объекту) в базе данных соответствует таблица. Затем для каждой таблицы базы данных приводится список полей записи.

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

Формирование концептуальной модели базы данных включает в себя:

- идентификацию функциональной деятельности предметной области;

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

- идентификацию характеристик этих сущностей;

- идентификацию взаимосвязей между сущностями;

- функциональную деятельность и формирования из их операций.

Основываясь на описании предметной области, приступим к выделению объектов и атрибутов, которые будут использованы при проектировании базы данных.

При детальном рассмотрении процесса подачи и регистрации исков в Каховском районном суде мною были выделены следующие объекты и их атрибуты:

1. Истец (код истца, ФИО, место жительства по прописке, место жительство фактическое, контактный телефон, идентификационный код, паспортные данные)

2. Ответчик (код ответчика, ФИО, место жительства по прописке, место жительство фактическое, контактный телефон, идентификационный код, паспортные данные)

3. Представитель ответчика (код представителя, ФИО, контактный телефон)

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

5. Вид иска (код типа иска, тип иска)

6. Перечень населенных пунктов (код населенного пункта, название населенного пункта)

Данные об объектах представим в виде таблиц.

 

Таблица 2.1 - Истец

Applicant_Table
Код позивача	ПІБ позивача	Адреса позивача за пропискою	Адреса проживання позивача	Телефон позивача	ПІБ представника позивача	ІК позивача	Паспортні дані позивача	Represent_id

 

Таблица 2.2 – Ответчик

Respondent_Table
Код відповідача	ПІБ відповідача	Адреса відповідача за пропискою	Адреса проживання відповідача	Телефон відповідача	ІК відповідача	Паспортні дані відповідача

 

Таблица 2.3 – Представитель ответчика

Aplicant_Represent_Table
Код представника позивача	ПІБ представника позивача	Телефон представника позивача

 

Таблица 2.4 – Иск

Claim_Table
Код заяви	Тип заяви	Дата подачі заяви	Виклад обставин, якими позивач обгрунтовує свої вимоги	Зазначення доказів, що підтверджують обставини, якими позивач обгрунтовує свої вимоги	Зміст позовних вимог	Перелік документів, що додаються до заяви	Назва документу в форматі MS Word	Applicant_id	Claim_type_id	Town_id	Respondent_id

 

Таблица 2.5 - Вид иска

Claim_Type_Table
Код типа заяви	Тип позову

 

 

Таблица 2.6 - Перечень населенных пунктов

List_of_Towns
Код міста	Назва міста