69100

Моделирование реляционной БД

Лекция

Информатика, кибернетика и программирование

Описание систем в виде объектов и взаимоотношений Модель реляционной базы данных Нормальные формы Введение В материалах предыдущей лекции были рассмотрены основные понятия связанные с архитектурой БД ORCLE. В частности: Определение СУБД; Основное назначение БД; Категории файлов данных.

Русский

2014-09-29

703.5 KB

0 чел.

PAGE   \* MERGEFORMAT 2

Лекция 1. Моделирование реляционной БД

Вопросы:

Описание систем в виде объектов и взаимоотношений

Модель реляционной базы данных

Нормальные формы

Введение

В материалах предыдущей лекции были рассмотрены основные понятия, связанные с архитектурой БД ORACLE. В частности:

Определение СУБД;

Основное назначение БД;

Категории файлов данных.

Основное внимание было уделено физической модели БД и ее взаимодействию со средствами операционной системы.

Целью настоящей лекции является рассмотрение логической модели БД и основных этапов ее создания.

1. Описание систем в виде объектов и взаимоотношений

Главная цель использования базы данных это сбор и эффективное хранение необходимой информации, чтобы ее можно было быстро обновлять и извлекать. Одна из проблем заключается в том, чтобы точно определить, какие данные требуются организации. Для ее решения разработчики вначале обязывают пользователей и менеджеров определить проблемы, которые требуется решить. Но дело в том, что пользователи обычно немного знают о базах данных. Поэтому вы должны спросить их о том, какие бизнес-операции и данные они собирают и используют при принятии решений. Затем вам нужно так организовать эту информацию, чтобы ее можно было эффективно хранить в базе данных. Если сможете, нарисуйте диаграмму и покажите ее пользователям, чтобы они подтвердили, что вы правильно поняли, как следует организовать информацию.

Для моделирования системы баз данных очень удобна модель "сущность связь'" (или классовый подход). Обращаем ваше внимание на то, что некоторые пользователи по-прежнему используют старую терминологию и обозначения диаграммы "сущность связь" (Entity-Relationship Diagram ERD). Позже были принята терминология и рисунки UML (Unified Modeling Language унифицированный язык моделирования). Общие принципы обоих подходов очень похожи и отличаются лишь построением диаграмм. Диаграммы UML легче читать, и этот подход стандартизован, следовательно, более универсален. Однако вы можете использовать термины и диаграммы по своему выбору.

Фундаментальным этапом моделирования является идентификация сущностей (или классов сущностей) для которых вы должны собирать данные. Каждая сущность (или класс) имеет атрибут, определяющий собираемые данные. Например, во многих базах данных распространена сущность Customer. Объект Customer имеет различные атрибуты: CustomerlD, Last Name, First Name, Phone, Address и City. Атрибуты представляют собой данные, собираемые для каждого класса. Например, определенный экземпляр данных Customer может иметь следующий вид: 151,   'Jones',   'Mary',   '111-2222',   '123 Main',   'Eureka'

В конечном счете вам еще нужно будет записать тип данных, содержащихся в каждом атрибуте. В предыдущем примере большинство атрибутов содержит текстовые данные, т.е. данные, которые содержат символы, числа и знаки препинания. Различные общие типы данных, которые вам наверняка встретятся, представлены в табл. 1.1. После того как вы определите, какие атрибуты будете хранить, вам потребуется записать тип данных, вмещаемых каждым атрибутом. Ситуация с некоторыми атрибутами сравнительно понятна, например, для записи адреса клиента используется тип данных Text. Относительно других атрибутов вам придется изучать существующие данные и консультироваться с пользователями. Типы данных Number и Date доступны для данных, задействованных в расчетах. Например, вы можете хранить в поле базы данных не возраст сотрудников, а даты их рождения. Позже, используя столбец "День рождения", вы сможете определить возраст каждого сотрудника, рассчитав разницу между текущей датой (по часам компьютера) и датой рождения сотрудника. Подобным образом номер счета можно считать строкой символов, поскольку вам вряд ли придется выполнять математические действия с атрибутом invoicelD. При этом поле цены единицы продукции в счете обязательно должно быть числовым, чтобы при расчетах эти поля можно было суммировать, рассчитывать произведение цены единицы товара на их количество и определить общую сумму за товар. Если сделать все позиции текстовыми, то вы сможете хранить и извлекать данные, но не сможете рассчитать суммы или вычислить разницу между двумя датами.

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

Данные ассоциации, соотношения или связи реализуются путем хранения связанных данных в похожих столбцах. Например, еще одним распространенным бизнес-объектом является Customer Order ("заказ клиента"), в котором записываются заказы, помещаемые клиентами (еще один объект). Customer Order содержит различные атрибуты, например OrderlD и OrderDate. Кроме того, он содержит атрибут CustomerlD, который предлагает связь с таблицей Customer. Например, определенный объект Customer Order может содержать такие данные: 1201, '06-JUN-2006', 151. Здесь 151 это CustomerlD ("идентификатор клиента"); зная это, вы можете просмотреть все остальные данные, найдя атрибут CustomerlD со значением 151 в объекте Customer.

На рис. 1.2 показано, как можно изобразить связь между объектами Customer и CustomerOrder. Каждый объект представлен прямоугольником, атрибуты расположены в прямоугольнике, в верхней части которого указано имя объекта. Соотношения между двумя объектами определяются с помощью соединительной линии. Как правило, ее рисуют для того, чтобы показать, что значения CustomerlD в классе CustomerOrder будут соединяться со значениями CustomerlD в таблице Customer. Примечание возле каждого конца линии указывает тип соотношения. В данном случае установлена зависимость типа "один ко многим", поскольку возле левого конца линии указана 1, а возле правого * (звездочка). Звездочка указывает на многосторонность отношения "один ко многим". Читая данную диаграмму слева направо, можно сказать, что клиент может помещать несколько заказов (это обозначено звездочкой) на правой стороне связи, обозначенной CustomerOrder. С другой стороны, любой заказ может поступать только от одного клиента, на что указывает цифра 1 на стороне связи, обозначенной Customer. Таким образом, если вы ищете форму заказа, то находите только одного клиента. Два клиента не могут подавать один заказ. Откуда вы это знаете? Таким образом представлено правило организации, поэтому либо вы должны знать, что это стандартный подход в бизнесе, либо вам должны сообщить об этом пользователи.

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

2. Модель реляционной базы данных

Исследования баз данных показали, что самым эффективным способом хранения и извлечения большей части информации являются реляционные базы данных. Чтобы добиться такой эффективности, к разработке базы данных необходимо подходить очень ответственно. Фундаментальным компонентом реляционной базы данных является таблица. Е. Ф. Кода (Е. F. Codd), признанный отец реляционных баз данных, разработавший этот подход, предпочитал термин связь (relation), а не таблица. Именно отсюда и пошел термин реляционные (relational) системы баз данных.

Таблица состоит из строк и столбцов и содержит данные, представляющие один объект в бизнес-модели. Ее столбцы называются атрибутами, а строки представляют отдельные экземпляры данных. Приведенную терминологию легче понять, обратившись к примеру, поэтому на рис. 1.3 показаны две таблицы гипотетической реляционной базы данных. Точнее, данные таблицы представляют диаграмму отношений, представленную на рис. 1.2. Обратите внимание на то, что каждая строка является простой, т.е. она представляет одну сущность. Каждый фрагмент данных является простым, поскольку содержит значения, описывающие одну концепцию. Например, вы не можете записать два номера телефона для одного человека. Если вам нужно будет записать несколько номеров телефона какого-то клиента, вы либо добавляете новые столбцы к таблице (CellPhone, HomePhone и т.д.), либо помещаете эту информацию в отдельную таблицу. Обратите также внимание на то, что таблицы связаны между собой посредством данных в столбце CustomerlD. Посмотрев на первую строку таблицы CustomerOrders, видим, что заказ был помещен клиентом с идентификатором 151. Это значение атрибута CustomerlD можно использовать для поиска информации, касающейся данного клиента, соответствующей строки таблицы Customers. Такое соединение таблиц не случайно, так как вы должны встроить его в структуры базы данных. Именно значения согласующего столбца в двух связанных таблицах позволяет системе баз данных соединять связанные строки двух таблиц. Другими словами, значения согласующего столбца в двух отдельных таблицах являются "клеем", позволяющим Oracle или другой системе баз данных синтезировать информацию по отдельным таблицам или фактам.

Первичные ключи

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

 Реляционная база данных это набор связанных таблиц. Таблица это набор строк и столбцов (атрибутов), описывающих объект. Атрибут это характеристика объекта. Строка содержит данные для одного экземпляра объекта.

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

В нашем простом примере генерируемым ключом, скорее всего, будет CustomerlD. Если система генерирует первичный ключ автоматически, то он будет уникальным. Но если первичный ключ создается вручную, то гарантировать его уникальность затруднительно. Пользователи могут делать ошибки и присваивать одно и то же значение двум клиентам особенно в большой системе или системе, в которой несколько пользователей взаимодействуют с базой данных и могут одновременно и независимо вводить первичные ключи. К счастью, Oracle содержит инструменты, позволяющие генерировать значения первичных ключей, которые гарантированно будут уникальными. Более того, вы можете указать Oracle автоматизировать процесс генерации ключей. В примере, показанном на рис. 1.3, ключ OrderlD может генерировать база данных, однако его может генерировать и отдел продаж    возможно, извлекая из напечатанной формы.

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

Вы вряд ли захотите использовать в качестве первичного ключа номер телефона из строки клиента. Что произойдет, если заказать товар пожелают два члена одной семьи? Нужно ли вам их различать? Рассмотрим худшую ситуацию: что произойдет, если клиент поменяет номер телефона, а старый номер достанется кому-то другому?

При работе с первичными ключами следует быть осторожными. Вы не будете генерировать новые ключи для каждой таблицы. Фактически вам часто придется работать с таблицами, в которых первичные ключи состоят из нескольких столбцов. Такие ситуации имеют особое значение, важное для понимания структуры реляционной базы данных. Если два (или более) столбца являются частью первичного ключа, это означает, что между объектами существует отношение ''многие ко многим", которое представляют эти ключи.

Пример отношения "многие ко многим'", которое вам, возможно, уже встречалось, приведен на рис. 1.4. Структура объекта Student понятна в нем содержатся общие данные о студенте (имя, фамилия, номер телефона). Объект Organization представляет собой клубы, спортивные команды и другие организации студенческого городка. Объект Participants занимает промежуточное положение в нем отслеживается, какие студенты являются членами каких организаций. В объекте Participants первичный ключ образуют атрибуты OrganizationID и StudentID. Для того чтобы уникальным образом определить строку таблицы, ключ должен содержать оба указанных столбца. Пример данных, составляющих таблицы, приведен на рис. 1.5.

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

3. Нормальные формы

Определение столбцов, используемых в качестве первичных ключей, является важным этапом разработки таблиц для реляционной базы данных. Тем не менее это не все. Каждая таблица в реляционной базе данных должна удовлетворять определенным условиям. Если эти условия не удовлетворяются, использование базы данных будет сопряжено с множеством проблем, включая потерю важных данных. Итак, как правило, вы начинаете с формы или описания данных. По ним вы создаете объекты. Затем благодаря процессу нормализации данные объекты превращаются в таблицы. Ниже мы подробно распишем процедуру создания таблиц с очень хорошими характеристиками. Проще всего понять данный процесс на примере. Рассмотрим его.

На рис. 1.6 показана стандартная бизнес-форма для заказа клиента. Посмотрите на форму и подумайте, можете ли вы определить основные объекты'.' Объект Customer сравнительно очевиден особенно из-за того, что он заключен в отдельную рамку. Если вы немного об этом подумаете, то можете прийти к выводу, что объектом может быть весь элемент CustomerOrder. Рассмотрим оставшиеся данные. Поскольку они также отображаются в отдельном прямоугольнике, заманчиво предположить, что упорядочиваемые элементы представляют третий и последний объект. Для начала ответ хороший, однако его нужно улучшить.

Для того чтобы понять, зачем нужна нормализация базы данных, попробуйте создать таблицу базы данных без планирования какой-либо структуры. Что произойдет, если все данные из формы Customer поместить в одну таблицу? На рис. 1.7 показано несколько элементов данных. Во-первых, обратите внимание на то, что вам не обязательно сохранять столбец Value, поскольку его можно вычислить по существующим данным.

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

Если вы попытаетесь ввести данные в предложенную таблицу, то быстро обнаружите ряд проблем в основном это чрезмерное количество повторов. Для каждой из трех заказанных вещей вам придется не только повторно вводить все данные заказа, но и все данные о клиенте. А постоянный повтор одних и тех же данных это бездумное расходование места. Однако есть и другие проблемы. Что произойдет, если клиент (Customer) 155 отметит свой заказ и вы удалите две строки таблицы? Вы потеряете всю информацию о клиенте! Другой вопрос: что вы можете сказать о продукте 1577? Он еще не заказан, поэтому для хранения указанных данных нет места; следовательно, вы не знаете ничего. Изучая предложенную таблицу, вы можете найти и другие проблемы подобного рода. Как исправить дизайн таблицы и избежать этих проблем? Гарантировать, что все таблицы соответствуют трем правилам нормализации (или трем нормальным формам)! Данные правила нормализации применяются последовательно, начиная с первой нормальной формы.

Первая нормальная форма

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

Если вы желаете уменьшить число очевидных повторов в форме, посмотрите, как организована таблица, приведенная на рис. 1.8. По многим показателям данный подход даже хуже рассмотренного выше, поскольку теперь реляционная база данных не знает, сколько элементов может быть заказано в каждой форме, поэтому планировать распределение места под базу данных довольно сложно, кроме того, затруднен и поиск в ней. Таблица, предложенная на рис. 1.8, не находится в первой нормальной форме. Это можно исправить с помощью повтора данных и сведения таблицы к виду, представленному на рис. 1.7, однако такое улучшение не кажется целесообразным. Вместо этого разумно разбить полученную таблицу на две новые. На те же две таблицы можно разбить и версию, представленную на рис. 1.7, руководствуясь, однако, другими причинами. По сути, вы извлекаете данные, находящиеся в повторяющемся блоке исходной таблицы, и помещаете их в новую таблицу. Тем не менее в новую таблицу вам нужно включить столбец OrderId, поскольку с его помощью полученные таблицы будут связаны между собой.

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

Вторая нормальная форма

Если вы внимательно посмотрите на вторую таблицу на рис. 1.9, то увидите, что проблемы по-прежнему существуют. Всякий раз, когда вы вводите ItemId 1526, вам нужно ввести описание и цену. Из-за траты места и времени на ввод данных внедрение информации о вещах в данную таблицу заказа означает, что вы по-прежнему никак не можете найти информацию о продуктах, которые еще не были заказаны. Проблема возникает из-за того, что описание вещи и цена зависят только от номера ItemId. Если рассмотреть элемент, значение ItemId которого равно 1526, то эта вещь будет иметь то же описание и цену, что и вчера. Данные значения не зависят от значения OrderId.

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

Подумайте еще раз о столбце цены. Фиксирована ли цена на вещь или зависит от конкретного заказа? Однозначного ответа на этот вопрос не существует, поскольку бизнес может вестись по различным правилам. Вопросы подобных зависимостей в различных организациях могут решать по-разному. Некоторые имеют традиционные ответы, пригодные для большинства случаев, однако вам необходимо поговорить с пользователями, чтобы понять, как они подходят к этой проблеме. Если вы создаете форму заказа для реальной компании, то, скорее всего, будете использовать две цены: прейскурантную цену, которая зависит только от ItemID, и отпускную цену, которая зависит от OrderlD и ItemID. Таким образом, компания может предлагать скидку, основываясь на любой выбранной характеристике. Для упрощения обсуждения далее мы будем предполагать, что каждая вещь имеет одну фиксированную цену.

Чтобы исправить таблицу, которая сейчас находится не во второй нормальной форме, вам нужно расщепить ее еще раз. Поместите столбцы, зависящие только от частичного ключа, в отдельную таблицу (рис. 1.10). Теперь таблицы Orderltems и Items находятся во второй нормальной форме. В действительности предложенная таблица order-customer также находится во второй нормальной форме, поскольку ее первичный ключ состоит из одного столбца.

Третья нормальная форма

В таблице order-customer (см. рис. 1.10) все еще имеются проблемы. Если мы вернемся к исходной таблице, приведенной на рис. 1.7, то увидим эти проблемы еще отчетливее. Для каждого заказа в таблице по-прежнему повторяется одна и та же информация о клиенте. В первоначальном варианте информация о клиенте повторялась для каждой заказанной вещи. Проблема заключается в том, что данные о клиенте (имя, адрес и пр.) зависят только от атрибута CustomerlD, но абсолютно не зависят от OrderlD. Если вы знаете значение атрибута CustomerlD, то знаете все о данном клиенте и вам совсем не нужен атрибут OrderlD.

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

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

В таблице Orders первичным ключом является OrderlD, который определяет дату заказа (OrderDate) и клиента, сделавшего заказ (CustomerlD). Ключом таблицы Customers является CustomerlD, а все остальные столбцы представляют атрибуты клиентов. Подобным образом ключом таблицы Items является ItemID, определяющий цену и описание вещи. Таблица Orderltems появилась из-за повторяющегося фрагмента в форме заказа. Атрибуты OrderlD и ItemID должны быть ключами из-за отношения "многие ко многим". Столбцы количества зависят от заказа и вещи, поэтому данная таблица также находится в третьей нормальной форме.

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

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

Соотношения и внешние ключи

На рис. 1.11 также показано, по какому принципу соединяются таблицы, чтобы с помощью данных можно было восстановить исходную форму. Данные соотношения не случайны. Вам следует быть очень аккуратными при расщеплении таолиц и следить за тем, чтобы их можно было объединить на основе соотношений. Как правило, данные связи настраиваются через ключевые столбцы, поскольку именно ключи являются эффективной ссылкой на исходные данные. Например, таблица Orders содержит значение CustomerlD, которое можно использовать для поиска связанных данных в таблице Customers.

Рассмотрим таблицу Orders более внимательно. Столбец OrderlD является первичным ключом, поскольку именно он требуется, чтобы гарантировать уникальность каждой строки. В частности, обратите внимание на то, что столбец CustomerlD не является частью первичного ключа в таблице Orders. Если бы мы не сделали его ключом, то можно было бы сказать, что между заказами и клиентами существует соотношение "множество множество", т.е. с данным заказом может быть связано несколько клиентов. В большинстве бизнес-транзакций такое утверждение ложно. Следовательно, в таблице Orders вы не должны вносить в ключ столбец CustomerlD.

Тем не менее, поскольку столбец CustomerlD является первичным ключом в таблице Customers, в таблице Orders он называется внешним ключом (foreign key). Позже вы увидите, что данная терминология очень важна в Oracle, поскольку отношения задаются через внешние ключи. Обратите внимание на то, что таблица Orderltems содержит два внешних ключа: OrderlD и ItemID, так как оба они являются первичными ключами в "родных" таблицах.

Обратите внимание на то, что таблицы Customers и Items не содержат внешних ключей. Иногда подобные таблицы называются базисными, поскольку содержащаяся в них информация не зависит от других таблиц. Достоинством базисных таблиц является то, что мы можем создать их и загрузить в них данные, не затрагивая связанные таблицы. И наоборот, если базе данных известна связь между внешним и первичным ключом, то вы не можете загрузить данные в таблицу Orders после создания нескольких клиентов. Например, если вы попытаетесь загрузить данные в таблицу Orderltems (см. рис. 1.11) до загрузки данных в таблицу Items, от которой зависят строки таблицы Orderltems, Oracle выдаст сообщение об ошибке. Точнее, если вы попытаетесь создать заказ и ввести значение CustomerlD, равное 190, вы должны уже иметь соответствующую строку в таблице Customers с таким значением ключа. Данное свойство называется целостностью на уровне ссылок (referential integrity) и означает, что вы не можете вставлять данные с одной стороны связи, если на другой стороне не существует согласующегося значения.


 

А также другие работы, которые могут Вас заинтересовать

16061. Патентознавство. Підручник 2.06 MB
  МІНІСТЕРСТВО ОСВІТИ І НАУКИ У КРАЇ і. І УЖГОРОДСЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ Л.М. Сусліков В.С. Дьордяй ПАТЕНТОЗНАВСТВО Рекомендовано Міністерством освіти і науки України як навчальнометодичний посібник для студентів КИЇВ 2005 вищих навчальних закладів ...
16062. Заведомо незаконное задержание, вопросы квалификации 446.5 KB
  МИНИСТЕРСТВО ВНУТРЕННИХ ДЕЛ РОССИИ СИБИРСКИЙ ЮРИДИЧЕСКИЙ ИНСТИТУТ П.Л. Сурихин ЗАВЕДОМО НЕЗАКОННОЕ ЗАДЕРЖАНИЕ: вопросы квалификации Учебное пособие КРАСНОЯРСК 2003 ББК 00.000 Сури
16064. Адвокатура в Российской Федерации 2.01 MB
  Происходящая в России демократизация политической и экономической системы, конституционное провозглашение правового социального государства вызывает необходимость коренной реорганизации форм и методов деятельности...
16065. Основи ораторського мистецтва 320 KB
  ББК 83. 079 Стец В.А. Стец І.І. Костючик М.Ю. Основи ораторського мистецтва. Навчальний посібник. Економічна думка Тернопіль 1998. 60 с. Посібник дає систематичне уявлення про ораторське мистецтво як прикладну і теоретичну дисципліну. Всебічно проаналізований процес о
16066. Сущность исполнения наказания 1.12 MB
  В монографии освещаются вопросы становления науки уголовно-исполнительного права, излагаются основы теории уголовно-исполнительного права, анализируется уголовно-исполнительная деятельность...
16067. Кримінально-виконавче право України 1.79 MB
  Навчальне видання Кримінальновиконавче право України Підручник За редакцією професора А. X. Степанюка Видання друге виправлене і доповнене Редактор А. В. Єфименко Комп'ютерна верстка і дизайн В. М. Зеленька Підписано до друку з оригіналмакета 01.11.2005. Формат ...
16068. Відповідальність юридичних осіб за податкові правопорушення 1.02 MB
  В книзі розглянуто види відповідальності за порушення податкового законодавства суб'єктами підприємницької діяльності. Зміст книги побудований на власному адвокатському досвіді автора, публікаціях фахівців з податкового права та чинному законодавстві. Акцент при викладенні матеріалу і при розгляді тих чи інших питань свідомо робиться з позицій платників податків.