Понятие о реляционных базах социологических данных
В настоящее время термины «база данных» и «системы управления базами данных» используются исключительно как относящиеся к компьютерам. В общем смысле термин «база данных» можно применить к любой совокупности связанной информации, объединенной вместе по определенному признаку. Например, в качестве базы данных можно рассматривать расписание движения поездов или книгу регистрации данных о заказах покупателей и выполнении заказов. При этом в качестве базы данных рассматривается только набор данных, организованных определенным образом. Поэтому записная книжка, если только не записывать в нее информацию в виде таблицы, не может считаться базой данных.
Для взаимодействия пользователя с базами данных используются системы управления базами данных (СУБД).
Современные СУБД обеспечивают:
• набор средств для поддержки таблиц и отношений между связанными таблицами;
• развитый пользовательский интерфейс, который позволяет вводить и модифицировать информацию, вы
поднять поиск и представлять информацию в текстовом или графическом виде;
• средства программирования высокого уровня, с помощью которых можно создавать собственные приложения.
В мире насчитывается более 50 типов СУБД для ПЭВМ. Среди них наиболее популярной в России для решения социологических задач является диалоговая система Fox-Pro, версии которой работают в среде WINDOWS.
Большинство баз данных, независимо от того, реализованы ли они на компьютере или нет, для хранения данных используют таблицы. Каждая таблица состоит из строк и столбцов, которые в компьютерных базах данных называются записями и полями соответственно.
Все записи состоят из одинаковых полей. Данные для одного поля во всех записях имеют одинаковый тип, но разные поля могут иметь разный тип данных.
Основные типы данных полей следующие:
• строка — содержит любую информацию в виде текста;
• число — содержит информацию в виде числа, как целого, так и десятичного;
• дата — содержит информацию в формате даты, например, ДД/ММ/ГГ, где ДД — день, ММ — месяц, ГГ — год.
Существуют также другие типы данных, имеющие меньшее применение.
В последнее время наибольшее распространение получили реляционные базы данных.
В реляционных базах данных информация хранится в одной или нескольких таблицах, что удобно для расположения социологической информации (например, в строках располагаются объекты обследования — респонденты, в столбцах — их ответы на поставленные в анкетах вопросы).
Связь между таблицами осуществляется посредством значений одного или нескольких совпадающих полей.
Каждая строка таблицы в реляционных базах данных уникальна. Для обеспечения уникальности строк используются ключи, которые содержат одно или несколько полей таблицы. Ключи хранятся в упорядоченном виде, что обеспечивает прямой доступ к записям во время поиска.
Каждая запись в таблицах идентифицирует один объект группы. Отношение между объектами определяет отношение между таблицами.
Основными видами отношений являются:
• один — к — одному;
• один — ко — многим;
• много — к — одному;
• много — ко — многим.
Рассмотрим эти виды отношений:
1. Отношение один — к — одному. Отношение один — к — одному означает, что каждая запись в одной таблице соответствует только одной записи в другой таблице. Данная связь поддерживается при помощи совпадающих по значению полей каждой таблицы.
2. Отношение один — ко — многим. В данном случае каждой записи в одной таблице ставится в соответствие несколько записей из другой. В этом случае связь между таблицами устанавливается также при помощи совпадающих по значению полей таблиц. Для примера этого отношения рассмотрим две таблицы, одна из которых хранит информацию о поставщиках, а вторая — о товарах, поставляемых ими.
3. Отношение много — к — одному. Отношение много — к — одному аналогично рассмотренному выше отношению один — ко — многим. Тип отношения зависит от точки зрения. Например, приведенное выше отношение можно рассматривать и как отношение много — к — одному: некоторому множеству товаров ставится в соответствие один определенный поставщик.
4. Отношение много — ко — многим.
Отношение много — ко — многим возникает между таблицами в тех случаях, когда:
Задавайте вопросы нашему консультанту, он ждет вас внизу экрана и всегда онлайн специально для Вас. Не стесняемся, мы работаем совершенно бесплатно!!!
Также оказываем консультации по телефону: 8 (800) 600-76-83, звонок по России бесплатный!
• одна запись из первой таблицы может быть связана более чем с одной записью из второй;
• одна запись из второй таблицы может быть связана более чем с одной записью из первой таблицы.
В качестве примера этого отношения можно привести следующие таблицы:
— таблица с информацией о товарах, производимых предприятиями-поставщиками;
— таблица с информацией о товарах, заказанных клиентами.
Между этими таблицами существует отношение много — ко — многим, так как на каждый поставляемый товар может быть более одного заказа. Аналогично каждый заказанный товар может производиться или поставляться более чем одним предприятием.
Связь между данными таблицами устанавливается на основании значений в совпадающих полях «Наименование товара».
Нормализация базы данных
При проектировании реляционной базы данных необходимо решить вопрос о наиболее эффективной структуре данных.
Основные цели, которые при этом преследуются:
• обеспечить быстрый доступ к данным в таблицах;
• исключить ненужное повторение данных, которое может являться причиной ошибок при вводе и нерационального использования дискового пространства компьютера;
• обеспечить целостность данных таким образом, чтобы при изменении одних объектов автоматически происходило соответствующее изменение связанных с ними объектов.
Процесс уменьшения избыточности информации в базе данных называется нормализацией. В теории нормализации баз данных разработаны достаточно формализованные подходы по разбиению данных, обладающих сложной структурой, среди нескольких таблиц,
Теория нормализации оперирует с пятью нормальными формами таблиц (от первой до пятой включительно).
Эти формы предназначены для уменьшения избыточности информации от первой до пятой формы. Поэтому каждая последующая нормальная форма должна удовлетворять требованиям предыдущей формы и некоторым дополнительным условиям. При практическом проектировании баз данных четвертая и пятая формы, как правило, не используются.
В качестве примера рассмотрим таблицу «Продажа», которая содержит следующую информацию:
Таблицу «Продажа» можно рассматривать как однотабличную базу данных. Основная проблема заключается в том, что в ней содержится значительное количество повторяющейся информации. Например, сведения о каждом покупателе повторяются для каждого товара, купленного им.
Такая структура данных является причиной следующих проблем, возникающих при работе с базой данных:
• большие затраты времени на ввод повторяющихся данных. Например, для всех покупок, сделанных одним из покупателей, необходимо вводить одни и те же данные о покупателе;
• при изменении адреса или телефона покупателя необходимо корректировать все записи, содержащие сведения о покупках этого покупателя;
• наличие повторяющейся информации приведет к неоправданному увеличению базы данных. В результате снизится скорость выполнения запросов. Кроме того, повторяющиеся данные нерационально используют дисковое пространство компьютера; при многократном вводе повторяющихся данных возрастает вероятность ошибки. При больших размерах таблицы поиск ошибок будет занимать значительное время.
Для устранения указанных недостатков применяется теория нормализации баз данных.
Первая нормальная форма.
Таблица в первой нормальной форме должна удовлетворять следующим требованиям:
2) в таблице должны отсутствовать повторяющиеся группы полей;
3) строки должны быть не упорядочены;
4) столбцы должны быть не упорядочены.
Для удовлетворения первого условия каждая таблица должна иметь уникальный индекс. Таблица «Продажа» не содержит уникального индекса, что допускает наличие в таблице повторяющихся записей. Для выполнения этого условия создадим уникальный индекс, содержащий поле КОД ПОКУПАТЕЛЯ.
Для удовлетворения второго требования необходимо разбить исходную таблицу на несколько таблиц так, чтобы не было повторяющихся групп полей.
Так как каждый покупатель может иметь несколько телефонов и сделать несколько покупок, в каждой из которых может быть несколько товаров, то необходимы четыре таблицы:
1) сведения об одном из покупателей;
2) список телефонов покупателя;
3) номер и дата накладной, данные о менеджере;
4) код, наименование, цена и количество проданного товара.
Условия 3 и 4 не имеют большого практического значения.
Поэтому с учетом ограничений (условия 3 и 4) мы можем считать, что таблицы «ПОКУПАТЕЛИ», «ТЕ ЛЕФ. ПОКУП.», «НАКЛАДНЫЕ» и «ТОВАР. НАКЛ.» находятся в первой нормальной форме.
Однако в первой нормальной форме еще существует избыточность данных. Для исключения этой избыточности переходят ко второй нормальной форме таблицы.
Вторая нормальная форма.
Чтобы таблица находилась во второй нормальной форме, она должна:
• удовлетворять условиям первой нормальной формы;
• иметь такую структуру, чтобы любое не ключевое поле однозначно идентифицировалось полным набором ключевых полей.
Из этого определения следует, что понятие второй нормальной формы применимо только к таблицам, имеющим составной индекс. В рассматриваемом примере такой таблицей является «ТОВАР. НАКЛ.», в которой составной индекс образуют поля «Номер накладной» и «Код товара». Данная таблица не является второй нормальной формой, так как поля «Товар», «Цена», «Категория товара» и «Количество» однозначно определяются только одним из ключевых полей («Код товара»), в то время как поля «Гарантийный срок» и «Количество» зависят и от «Номер накладной».
Для приведения таблицы ко второй нормальной форме необходимо выделить из таблицы «ТОВАР, НАКЛ.» таблицу «ТОВАРЫ», которая будет содержать информацию о товарах каждого типа. Для связывания таблиц «ТОВАР. НАКЛ.» и «ТОВАРЫ» используется поле «Код товара».
Таблицы, находящиеся во второй нормальной форме, в общем случае также содержат некоторую избыточность данных. Поэтому вводят понятие третьей нормальной формы.
Третья нормальная форма.
Таблица находится в третьей нормальной форме, если:
• она удовлетворяет условиям второй нормальной формы;
• ни одно из не ключевых полей таблицы не идентифицируется с помощью другого не ключевого ноля.
Сведение таблицы к третьей нормальной форме предполагает разделение таблицы с целью помещения в отдельную таблицу (или несколько таблиц) столбцов, которые не зависят от полного ключа. В результате такого разбиения каждое из не ключевых полей должно оказаться независимым от какого-либо другого не ключевого поля.
В нашем примере рассмотрим таблицу «НАКЛАДНЫЕ». Поле «Менеджер» этой таблицы содержит имена менеджеров, которые однозначно определяются значением поля «Код менеджера». Поскольку не ключевое поле «Менеджер» однозначно определяется другим не ключевым полем, данная таблица не является таблицей в третьей нормальной форме. Для приведения этой таблицы к третьей нормальной форме создадим новую таблицу «МЕНЕДЖЕР».
В реально существующих базах данных обычно применяют таблицы, находящиеся в третьей нормальной форме.
Создание таблицы базы данных социологического обследования коммерческой фирмы
Для работы практически любой коммерческой фирмы необходимо большое количество разнообразной информации. Например, для ведения складского хозяйства требуются данные о товаре на складе, его поступлениях и выдаче. Для посреднических фирм следует
хранить информацию о потенциальных клиентах покупателях и предприятиях-поставщиках, выпускающих товары, а также данные о самих товарах. Для ведения бухгалтерской документации необходимо хранить информацию о приходных и расходных кассовых ордерах, накладных, платежных поручениях, различные данные для расчета заработной платы, составления баланса и различных отчетов.
Следовательно, необходимы базы данных с информацией о товарах, бухгалтерских и других документах, клиентах.
Всю эту информацию можно хранить как в одной универсальной базе данных, так и в нескольких специализированных. Применение одной универсальной базы данных позволяет повысить удобство работы с программами, увеличить возможности базы данных. Однако при такой базе данных усложняются программы, работающие с ней, а также возрастает объем самой базы данных.
Но иногда не требуется хранить все данные, например, если бухгалтерия ведется без применения компьютеров или с применением специальных программ со своими базами данных. Поэтому, если на практике необходимо использовать только часть возможностей универсальной базы данных, то следует применять специализированные базы данных.
Произведем проектирование универсальной базы данных для коммерческой фирмы.
Для хранения полной информации о работе коммерческой фирмы необходимо обеспечить работу программы со следующими данными:
• о постоянных клиентах (адрес, телефон, расчетный счет и т.д.);
• о наличии товара на складе (количество, цена, дата поступления и т.д.);
• о выписанных приходных и расходных накладных (кому и когда, какой товар, на какую сумму и т.п.);
• о выписанных счетах (кому и когда, на какой товар, на какую сумму, оплачен ли он);
• о выставленных платежных поручениях (кому и когда, на какую сумму).
Рассмотрим первоначальную структуру требуемых таблиц, а также произведем их нормализацию с учетом определенных выше требований.
Пусть в результате анкетирования покупателей фирмы получена информацию о постоянных клиентах и поставщиках товаров.
Рассмотрим основные данные, предназначенные для хранения в базе данных. Основная часть этих данных связана с информацией о реквизитах и адресах предприятий, их руководителях. Некоторые поля предназначены для хранения информации о текущих финансовых взаимоотношениях с этими предприятиями, о скидках при покупке, которые имеют эти клиенты. Создание подобной таблицы позволит автоматизировать процесс заполнения различных документов, накладных, счетов.
Данная таблица не нормализована, так как любой клиент может иметь несколько телефонов, следовательно, информация во всех остальных полях будет повторяться для каждого телефона клиента.
Для приведения этой таблицы в первую нормальную форму следует выделить из нее поля «Код клиента» и «Телефон» в отдельную таблицу. Эти две таблицы будут связаны по полю «Код клиента». В этом случае обе таблицы будут иметь ключевое поле «Код клиента», которым однозначно определяются все остальные неключевые поля в обеих таблицах. Следовательно, эти таблицы находятся во второй нормальной форме. Данные таблицы находятся также и в третьей нормальной форме, так как ни одно из неключевых полей не определяется через другое не ключевое поле, а все поля зависят только от поля «Код клиента».
Создание таблиц с информацией о товарах на складе
В данной таблице должна храниться информация о товаре, его производителе, цене, количестве, дате выпуска и т.д. Также здесь будут храниться данные о непосредственном поставщике товара, приходной накладной о приеме данного товара. Применение такой таблицы позволит получать наиболее полную информацию о товарах, имеющихся на складе.
Данная таблица также не нормализована, так как существует несколько групп повторяющихся полей:
• для каждого товара, поступившего от одного поставщика, будут повторяться поля, содержащие информацию об этом поставщике: «Код поставщика», «Поставщик», «Реквизиты поставщика»;
• для каждого товара, принятого на склад по одной накладной, будут повторяться поля: «Дата поступ.», «Номер наклад.», «Оплата».
Для приведения данной таблицы к первой нормальной форме необходимо разбить ее на три таблицы, первая таблица — с информацией о товарах, вторая — с информацией о поставщиках, третья — с информацией о приходных накладных.
Полученные таблицы находятся также и во второй, и в третьей нормальных формах, так как выполняются соответствующие условия. Следовательно, дальнейшая нормализация таблиц не требуется. Информацию о поставщиках товаров можно хранить в таблице «ПОСТОЯННЫЕ КЛИЕНТЫ», а их телефоны в таблице «ТЕЛЕФОНЫ ПОСТ. КЛИЕНТОВ» (эти две таблицы разработаны ранее).
В ресторане за один столом сидела две мамы и столько-же дочерей. Официант подал к столу три кофе, и при этом всем досталось по чашке. Как это возможно?
Статью подготовила доцент кафедры социально-гуманитарных дисциплин Волгушева Алла Александровна. 
