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) и означает, что вы не можете вставлять данные с одной стороны связи, если на другой стороне не существует согласующегося значения.


 

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

37286. Автогенератор с автотрансформаторной обратной связью 815.67 KB
  Коэффициент обратной связи на резонансной частоте 8. Поэтому коэффициент обратной связи оказался независимым от частоты что справедливо при относительно невысоких частотах в половину меньших граничной частоты транзистора. С повышением частоты схема замещения автогенератора усложняется и коэффициент обратной связи должен рассматриваться с учетом перечисленных факторов. Амплитуда генерируемых колебаний определяется из уравнения баланса амплитуд Регулировка амплитуды колебаний производится изменением величины коэффициента обратной...
37287. Особенности ведения и учета налога на прибыль бюджетными организациями 432.5 KB
  Налоговый учет осуществляется для формирования полной и достоверной информации о порядке учета для целей налогообложения хозяйственных операций, осуществленных налогоплательщиком в течение отчетного (налогового) периода, а также обеспечения информацией внутренних и внешних пользователей для контроля за правильностью исчисления, полнотой и своевременностью исчисления и уплаты в бюджет налога.
37288. Расчеты сметы затрат на проектирование сегментов локальной вычислительной сети в здании ГВЦ ОАО НЛМК 175.5 KB
  Организуется автоматизированный документооборот электронная почта создаются различные массивы управленческой коммерческой и другой информации общего назначения и персонально используются вычислительные ресурсы всей сети а не только отдельного компьютера. Таким образом решится проблема окупаемости и рентабельности внедрения корпоративной сети. С внедрением на предприятии компьютерного оборудования и подключением к глобальной сети Internet организация получает практически неограниченные информационные возможности оперативное получение...
37289. Бюджетно-финансовая политика 141 KB
  Государственные финансы – это все финансовые средства государственных организаций. Они включают в себя государственный бюджет и внебюджетные денежные фонды, которые находятся в ведении государства (пенсионный фонд, фонд социального страхования, фонд обязательного медицинского страхования).
37290. Влияние копинг-поведения на уровень эмоционального выгорания медицинских сестер 234.71 KB
  Изучить феномен психического выгорания как социально-психологическую проблему; подобрать диагностический инструментарий; выявить особенности эмоционального выгорания медицинских сестер с различным типом копинг-поведения; разработать программу тренинга по формированию навыков снятия эффекта эмоционального выгорания.
37291. ПРИВОД ЛЕБЕДКИ 3.8 MB
  Привод лебедки. Целью курсового проекта по дисциплине Детали машин и основы конструирования является приобретение первых инженерных навыков по расчётам и конструированию деталей и узлов машин на основе полученных теоретических знаний.
37293. Социология. Шпаргалка 315 KB
  Принято считать что объектом социологического познания является вся совокупность свойств связей и отношений которые носят название социальных. В марксизме предметом социологического исследования является научное изучение общества как социальной системы и составляющих его структурных элементов личностей социальных обшностсй социальных институтов. Она предстает как система взаимосвязанных представлений понятий взглядов теорий о социальных процессах разных уровней жизнедеятельность отдельных людей социальных групп или...