Программное обеспечение маркетинговых исследований Системы управления базами данных маркетинга Развитие компьютерных технологий, связанных с хранением и обработкой данных, привело к появлению в конце 60 х – начале 70 х гг. ХХ века специализированного программного обеспечения, получившего название системы управления базами данных (СУБД). СУБД позволяют структурировать, систематизировать и организовывать данные для их компьютерного хранения и обработки. Именно системы управления базами данных являются основой практически любой информационной системы. 1 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 1. Понятие базы данных База данных (БД) – это совокупность структурированные данных, относящихся к определенной предметной области и допускающей их оптимальное использование для одного или нескольких приложений. При этом данные должны быть непротиворечивы, минимально избыточны и целостны. Система управления базами данных (СУБД) – это комплекс программных и языковых средств, необходимых для создания баз данных, поддержания их в актуальном состоянии, обеспечение доступа пользователей к ней и организации поиска в них необходимой информации. Централизованный характер управления данными в базе данных предполагает необходимость существования некоторого лица (группы лиц), на которое возлагаются функции администрирования данными, хранимыми в базе (администратор БД). 2 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 1. Понятие базы данных Обычно БД создается для хранения и доступа к данным, содержащим сведения о некоторой предметной области, то есть некоторой области человеческой деятельности или области реального мира. Всякая БД должна представлять собой систему данных о предметной области. БД, относящиеся к одной и той же предметной области, в различных случаях содержат более или менее детализированную информацию о ней. Степень детализации определяется рядом факторов, прежде всего целью использования информации из базы данных и сложностью производственных (деловых) процессов, существующих в пределах предметной области в конкретных условиях. 3 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 1. Понятие базы данных База данных предполагает централизованное управление данными, что обеспечивает ряд преимуществ: ü сокращение избыточности хранимых данных благодаря однократному хранению каждого сообщения в базе данных, ü совместное использование хранимых данных всеми пользователями ЭИС, ü стандартизацию представления данных, упрощающую проблемы эксплуатации БД и обмена данными между ЭИС, ü обеспечение процедур проверки достоверности информации и процедур ограничения доступа к данным, ü совмещение требований к использованию БД со стороны различных пользователей ЭИС. 4 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 2. Модели баз данных Ядром любой базы данных является модель данных. Модель данных представляет собой множество структур данных, ограничений целостности и операций манипулирования данными. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними. БД основываются на использовании иерархической, сетевой или реляционной модели, на комбинации этих моделей, или на некотором их подмножестве. 5 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 2. 1. Иерархическая модель данных Иерархическая структура представляет совокупность элементов, связанных между собой по определенным правилам. 6 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 2. 1. Иерархическая модель данных Объекты, связанные иерархическими отношениями, образуют ориентированный граф (перевернутое дерево). К основным понятиям иерархической структуры относятся: уровень, элемент (узел), связь. Узел – это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т. д. уровнях. Количество деревьев в базе данных определяется числом корневых записей. К каждой записи базы данных существует только один (иерархический) путь от корневой записи. Для того, чтобы получить элемент данных А 12, нужно сначала отыскать в БД узел А, спуститься к узлу А 1 и затем – к узлу А 12. 7 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 2. 2. Сетевая модель данных В сетевой БД при тех же основных понятиях (уровень, узел, связь) каждый элемент может быть связан с любым другим элементом, Сетевая БД характерна внутренними ссылками между структурами данных. Если от элемента В имеется ссылка на элемент А, возможен выбор элемента данных А. 8 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 2. 3. Реляционная модель данных Реляционная база данных – база данных, организованная в виде набора отношений ее компонентов. Реляционные БД представляют связанную между собой совокупность таблиц баз данных (ТБД). Связь между таблицами может находить свое отражение в структуре данных, а может только подразумеваться, то есть присутствовать на неформализованном уровне. Каждая таблица БД представляется как совокупность строк и столбцов, где строки соответствуют экземпляру объекта, конкретному событию или явлению, а столбцы – атрибутам (признакам, характеристикам, параметрам) объекта, события, явления. Предшественниками реляционных БД были иерархические и сетевые базы данных. 9 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 2. 3. Реляционная модель данных Пример таблицы БД, в которой содержатся сведения об отпуске товара со склада: 10 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 2. 3. Реляционная модель данных Столбцы представляют собой такие параметры, как дата отпуска товара, наименование отпущенного товара, наименование покупателя, количество единиц отпущенного товара. Каждая строка содержит сведения о конкретном событии отпуска товара покупателю. В терминологии теории реляционных БД таблицам соответствуют отношения, столбцам – атрибуты, строкам – кортежи. При практической разработке БД таблицы так и зовутся таблицами, строки – записями, столбцы – полями или столбцами ТБД. Эти модели характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных. 11 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 2. 3. Реляционная модель данных Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами: Ø каждый элемент таблицы – один элемент данных; Ø все столбцы в таблице однородные, т. е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д. ) и длину; Ø каждый столбец имеет уникальное имя; Ø одинаковые строки в таблице отсутствуют; Ø порядок следования строк и столбцов может быть произвольным. Реляционные БД имеют мощный теоретический фундамент, основанный на математической теории отношений. Понятие реляционный (англ. relation – отношение) связано с разработками известного американского специалиста в области систем баз данных доктора Эдгара Кодда. 12 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 2. 3. Реляционная модель данных Для построения запросов к реляционным БД был также разработан язык SQL (Structured Query Language, язык структурированных запросов). Он приобрел характер промышленного стандарта в реляционных системах управления базами данных (СУБД). Поэтому, переходя с одной реляционной базы на другую, пользователь и разработчик имеют дело с одним и тем же языком. Другим важным плюсом SQL является то, что язык ориентирован на высокоуровневые операции с данными. Выдавая запрос, можно не беспокоиться о низкоуровневых проблемах доступа к данным, специфичных для каждой БД, поскольку интерпретация запросов в команды низкого уровня лежит в ведении конкретной СУБД. 13 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 3. Понятие первичного ключа В каждой таблице БД может существовать первичный ключ. Под первичным ключом понимают поле или набор полей, однозначно идентифицирующий запись. Значение первичного ключа в таблице БД должно быть уникальным, то есть в таблице не должно существовать двух или более записей с одинаковым значением первичного ключа. Первичный ключ должен быть минимально достаточным: в нем не должно быть полей, удаление которых из первичного ключа не отразится на его уникальности. 14 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 3. Понятие первичного ключа В качестве первичного ключа не могут использоваться поля: ü ФИО – поскольку практически известно, что даже в одном отделе могут работать однофамильцы с одинаковыми инициалами или даже полные тезки; ü должность – поскольку, хотя для данного примера названия должностей и уникальны, в любом отделе наверняка найдутся сотрудники, занимающие одинаковую должность; ü номер отдела и год рождения – поскольку здравый смысл подсказывает, что может найтись достаточное число сотрудников, работающих в одном отделе или родившихся в одном году. В качестве первичного ключа может выступать номер пропуска, но при этом нужно сделать оговорку. Если номер пропуска недавно уволившегося сотрудника не может быть назначен сотруднику, впоследствии принятому на работу (т. е. является уникальным во времени), нет никаких ограничений на использование этого поля в качестве первичного ключа. 15 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 3. Понятие первичного ключа Если же номер пропуска уволившегося сотрудника может быть назначен вновь поступившему сотруднику, следует изучить вопрос – удаляется ли информация об уволившемся сотруднике из базы данных? Если да, то поле может быть первичным ключом; если нет – не может быть первичным ключом, поскольку в базе данных могут присутствовать два сотрудника с одинаковым номером пропуска. Уникальность подобного поля обычно отслеживается или программно, или автоматически. В первом случае, при добавлении нового сотрудника приложение, работающее с базой данных, отыскивает максимальный номер сотрудника, увеличивает на 1 и назначает вновь добавляемой записи. Во втором случае, первичный ключ реализуется через автоинкрементное поле. Для него указанные действия выполняются автоматически системой управления базой данных. Существуют и иные способы обеспечения уникальности значений ключевого числового поля, они зависят от особенностей конкретной СУБД. 16 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 3. Понятие первичного ключа В приводившейся выше таблице "Отпуск товаров со склада" также необходимо генерировать семантически незначащий первичный ключ, поскольку, как несложно заметить, один и тот же покупатель может в течение одного и того же дня многократно закупать один и тот же товар в одинаковом количестве. Однако, если предметная область допускает использование семантически значащего уникального поля, следует использовать его, например, для расхода товаров. Это может быть номер накладной или номер счета, при условии, что в организации существуют деловые правила, согласно которым один и тот же номер не может быть назначен двум счетам или накладным. 17 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 3. Понятие первичного ключа Другие примеры первичных ключей: ü номер и серия паспорта; ü номер двигателя; ü фамилия и инициалы автора, название книги, год издания; ü название факультета, кафедры, года приема – для именования учебных групп в вузах; ü номер лицевого счета в бухгалтерском балансе; ü дата – если событие может случиться в течение даты только единожды, например, поставка товара на склад; ü дата и время отказа сетевого оборудования, а при наличии нескольких потенциально сбойных узлов – адрес (номер) узла (если сбой узла характеризуется несколькими типами ошибок – еще и номер ошибки); ü почтовый адрес организации – с указанием номеров комнат (в случае, если в одном офисе располагается несколько организаций); ü банковские реквизиты; ü регистрационный номер банка, организации. 18 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 4. Связи между таблицами Между двумя или более таблицами базы данных могут существовать отношения подчиненности. Отношения подчиненности определяют, что для каждой записи главной таблицы (master, называемой еще родительской) может существовать одна или несколько записей в подчиненной таблице (detail, называемой еще дочерней). Существуют четыре разновидности связей между таблицами базы данных: ü один к одному (1: 1); ü один ко многим (1: М); ü многие к одному (M: 1); ü многие ко многим (М: N). 19 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 4. Связи между таблицами Связь 1: 1 (связь один к одному) обозначает такой тип связи между двумя объектами А и В, когда каждому экземпляру объекта А соответствует один и только один экземпляр объекта В. Например, отношение "один-к-одному" имеет место, когда одной записи в родительской таблице "Сотрудник" соответствует одна запись в дочерней таблице "Паспорт". 20 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 4. Связи между таблицами Данное отношение встречается много реже, чем отношение "одинко-многим". Его используют, если не хотят, чтобы таблица БД "распухала" от второстепенной информации. Использование связи "один-к-одному" приводит к тому, что для чтения связанной информации в нескольких таблицах приходится производить несколько операций чтения вместо одной, когда данные хранятся в одной таблице. Кроме того, базы данных, в состав которых входят таблицы со связью "один-к-одному", не могут считаться до конца нормализованными. Связь "один-к-одному" может быть жесткой и нежесткой. В первом случае, для каждой записи в родительской таблице должна существовать запись в дочерней таблице. Во втором случае, запись в дочерней таблице может как существовать, так и отсутствовать. 21 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 4. Связи между таблицами Связь 1: М (связь один ко многим) обозначает такой тип связи между двумя объектами, когда одному экземпляру объекта А может соответствовать 0, 1 или несколько экземпляров объекта В. Но каждому экземпляру объекта В соответствует только один экземпляр объекта А. Например, отношение "один-ко-многим" имеет место, когда одной записи родительской таблицы "Сотрудник" может соответствовать несколько записей в дочерней таблице "Ребенок". 22 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 4. Связи между таблицами Как видно из рисунка, одной записи из родительской таблицы "Сотрудник" может соответствовать несколько записей в дочерней таблице "Ребенок". Обратите внимание на глагол может, он означает, что такая возможность – потенциальная, и что в родительской таблице могут найтись записи, для которых в данный момент нет записей в дочерней таблице (например, у сотрудника с табельным номером 113 нет детей). Поэтому различают две разновидности связи "один-ко-многим". В первом случае, выдвигается жесткое требование, согласно которому всякой записи в родительской таблице должны соответствовать записи в дочерней таблице. Во втором случае, подобное требование не носит жесткого характера и подразумевается (как в описанном выше случае), что некоторые записи в родительской таблице могут не иметь связанных с ними записей в дочерней таблице. 23 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 4. Связи между таблицами Связь "один-ко-многим" иногда называют связью "многим-кодному". В этом случае подразумевается, что мы смотрим со стороны дочерней таблицы на родительскую. Когда упоминают название "одинко-многим", имеется в виду, что следует смотреть со стороны родительской таблицы на дочернюю. И в том и в другом случае сущность связи между таблицами остается неизменной. Связь "один-ко-многим" является самой распространенной для реляционных" баз данных. Как можно заметить, она позволяет моделировать иерархии данных. 24 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 4. Связи между таблицами Связь M: 1 (связь многие к одному) является обратной связи 1: М. Например, на следующем рисунке показаны таблицы, состоящие в отношении "многие-к-одному". Несколько записей родительской таблицы "Сотрудник" соответствуют одной записи в дочерней таблице "Подразделение". 25 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 4. Связи между таблицами Связь M: N (связь многие ко многим) обозначает такой тип связи между двумя объектами, когда каждому экземпляру объекта А может соответствовать 0, 1 или несколько экземпляров объекта В, и наоборот. На следующем рисунке показаны таблицы, состоящие в отношении "многие-ко-многим". 26 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 4. Связи между таблицами Одной записи родительской таблицы "Сотрудник" соответствуют несколько записей в дочерней таблице "Иностранный язык", и наоборот, одной записи дочерней таблицы " Иностранный язык" соответствуют несколько записей в родительской таблице " Сотрудник". Отношение "многие-ко-многим" имеет место, когда: а) записи в родительской таблице может соответствовать больше одной записи в дочерней таблице; б) записи в дочерней таблице может соответствовать больше одной записи в родительской таблице. Многие СУБД не поддерживают связи "многие-ко-многим" на уровне индексов и ссылочной целостности, хотя и позволяют реализовывать ее в таблицах неявным образом. Аналогично, многие CASE средства (программы для разработки структуры базы данных в виде диаграмм и генерации на их основе физической базы данных) также не позволяют определять эту связь между таблицами базы данных. Считается, что всякая связь "многие-ко-многим" может быть заменена на одну или более связь "один-ко-многим". 27 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений При проектировании структуры новой БД определяют сущности (объекты, явления) предметной области, которые должны найти свое отражение в базе данных. Анализ предметной области обычно осуществляется: ü на основании существующих сведений о предметной области в широком или в узком смысле, то есть в масштабах, в которых она должна быть представлена в создаваемой БД и работающих с ней приложениях; ü исходя из целей проектирования программной системы; ü на основании представления о том, какое место БД и работающие с ней приложения займут в структуре эксплуатирующей ее организации; ü на основании представлений о том, какие изменения деловых потоков организации последуют после внедрения программной системы в эксплуатацию. 28 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Анализ предметной области должен привести к созданию эскиза БД. Сначала желательно изобразить сущности и связи между ними. Как правило, каждой сущности в БД соответствует таблица. Затем – в эскизе второго порядка – для каждой таблицы БД приводится список полей записи. Несмотря на существование методик анализа предметных областей, построения эскизов БД (весьма полезных при больших объемах обрабатываемых данных и деловых правил в предметной области, нередко выходящих за рамки одновременного восприятия), необходимо отметить следующее: ü процесс определения окончательной структуры БД является циклическим, то есть на разных этапах проектирования, начиная от эскиза структуры БД и заканчивая опытной или даже промышленной эксплуатацией готовых программных систем, приходится возвращаться к структуре БД и вносить в нее изменения; 29 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений ü в процессе моделирования предметной области участвуют такие субъективные факторы, как здравый смысл разработчика, его интуиция, привычки, личностное восприятие проблемы, стереотипы мышления и т. д. Поэтому различные разработчики наверняка предложат различные проекты структуры одной и той же БД, хотя в узловых моментах, например, в определении большей части сущностей и связей между ними, эти проекты должны быть похожи. Следовательно, с одной стороны, процесс проектирования структур БД является процессом творческим, неоднозначным, с другой стороны, узловые его моменты могут быть формализованы. Одним из важнейших требований к реляционной БД является требование, согласно которому реляционная база данных должна быть нормализована (то есть подвергнута процедуре нормализации). 30 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений – формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных. Процесс нормализации имеет своей целью устранение избыточности данных и заключается в приведении к третьей нормальной форме (ЗНФ). Существует несколько нормальных форм – 1 НФ, 2 НФ, ЗНФ, 4 НФ, 5 НФ, нормальная форма Бойса Кодда (БКНФ). При практической разработке баз данных важны первые три – 1 НФ, 2 НФ, ЗНФ. В. Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме. 31 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Одни и те же данные могут группироваться в таблицы (отношения) различными способами, т. е. возможна организация различных наборов отношений взаимосвязанных информационных объектов. Группировка атрибутов в отношениях должна быть рациональной, т. е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления. Определенный набор отношений обладает лучшими свойствами при включении, модификации, удалении данных, чем все остальные возможные наборы отношений, если он отвечает требованиям нормализации отношений. Первая нормальная форма (1 НФ) требует, чтобы каждое поле таблицы БД: ü было неделимым; ü не содержало повторяющихся групп. 32 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Неделимость поля означает, что значение поля не должно делиться на более мелкие значения. Например, если в поле "Подразделение" содержится название факультета и название кафедры, требование неделимости не соблюдается и необходимо из данного поля выделить или название факультета, или кафедры в отдельное поле. Повторяющимися являются поля, содержащие одинаковые по смыслу значения. Например, если требуется получить статистику продаж четырех товаров по месяцам, можно создать поля для хранения данных о продаже по каждому товару. В этом случае мы имеем дело с повторяющимися группами: 33 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Однако, что делать, если товаров не 4, а 104? Конечно, можно определить столько полей, сколько товаров. Но как быть, если число товаров заранее не известно и по одной накладной может быть отпущено 2, а по другой – 772 товара? Реализовать запись с переменным числом полей в реляционных базах данных невозможно, поскольку запись таблицы реляционной БД должна иметь четкую структуру. Исходя из вышесказанного, повторяющиеся группы следует устранить. В результате получим запись, содержащую информацию о статистике продаж по одному товару: Для 4 товаров будем иметь 4 записи, для 104 товаров – 104 записи и для п товаров – п записей для каждого месяца. 34 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Пример. Необходимо автоматизировать процесс отпуска товаров со склада. Товары отпускаются по накладной следующего вида: 35 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Таблица, приведенная к 1 НФ: Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа. 36 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Вторая нормальная форма (2 НФ) требует, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен. Те поля, которые зависят только от части первичного ключа, должны быть выделены в составе отдельных таблиц. Продолжим рассмотрение описанного выше примера. Для приведения к 2 НФ выделим поля, которые входят в первичный ключ. Дата накладной и номер накладной по отдельности не могут уникально определять запись, поскольку они будут одинаковы для всех записей, относящихся к одной и той же накладной. Поэтому введем в первичный ключ поле "Товар". При этом исходим из имеющегося правила, что по одной накладной может быть отпущено одно наименование конкретного товара, то есть не может иметь место ситуация, когда отпуск одного и того же товара оформляется в накладной двумя строками, что влечет за собой две одинаковые записи в таблице "Отпуск товаров со склада". 37 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений 38 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Структура таблицы "Отпуск товаров со склада" после выделения полей в составе первичного ключа (эти поля отчеркнуты от прочих полей линией и располагаются в верхней части структуры таблицы): 39 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Проведя смысловой анализ зависимостей между полями таблицы, нетрудно увидеть, что созданный нами первичный ключ является избыточным: поле "Номер накладной" однозначно определяет дату и покупателя. Для данной накладной не может быть никакой иной даты и никакого иного покупателя. Поле "Товар'', будучи взято в комбинации с номером накладной, напротив, однозначно идентифицирует запись, поскольку для каждой записи ясно, о каком, собственно, товаре из множества товаров, отпущенных по данной накладной, идет речь. После уточнения состава полей в первичном ключе получим таблицу со следующей структурой: 40 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Первое требование 2 НФ выполнено. Чего не скажешь о втором требовании, гласящем, что значения всех полей записи должны однозначно зависеть от совокупного значения первичного ключа и не должна иметь место ситуация, когда некоторые поля зависят от части первичного ключа. Действительно, при дальнейшем анализе можно увидеть, что поля "Единица измерения", "Цена за единицу измерения" зависят только от значения поля "Товар". В самом деле, стоимость единицы измерения товара и название самой единицы измерения не зависят от конкретной накладной и будут одинаковыми для всех накладных, в которые входит данный товар. Поэтому выделяем данные поля в отдельную таблицу "Товары" и определяем связь: поскольку один товар может присутствовать во многих накладных, таблицы "Товары" и "Отпуск товаров со склада" находятся в связи "один ко многим". 41 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений 42 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений После анализа структуры таблицы "Отпуск товаров со склада" можно заметить, что значение поля "Покупатель" никоим образом не зависит от пары значений "Номер накладной", "Товар", а зависит только от значения поля "Номер накладной". Поэтому данное поле и, зависящие от его значения поля "Город", "Адрес", выделяются в отдельную таблицу "Покупатели''. 43 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Анализируя далее структуру таблицы "Отпуск товаров со склада", можно заметить, что одно из оставшихся полей – "Дата" зависит только от значения поля "Номер накладной". Поэтому выделяем дату и номер накладной в отдельную таблицу "Накладные". 44 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Установим связи между таблицами. Один покупатель может встречаться во многих накладных. Поэтому между таблицами "Покупатели" и "Накладные" имеется связь "один ко многим" по полю "Покупатель". Одной накладной может соответствовать несколько товаров. Поэтому между таблицами "Накладные" и "Отпуск товаров со склада" имеется связь "один ко многим" по полю "Номер накладной". 45 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Для того чтобы уяснить, до конца нормализованы таблицы в составе разрабатываемой нами БД или нет, проанализируем ее структуру с позиций третьей нормальной формы (ЗНФ). Третья нормальная форма (ЗНФ) требует, чтобы в таблице не имелось транзитивных зависимостей между не ключевыми полями, то есть, чтобы значение любого поля таблицы, не входящего в первичный ключ, не зависело от значения другого поля, не входящего в первичный ключ. Продолжим рассмотрение примера. Можно увидеть, что в таблице "Отпуск товаров со склада" имеется зависимость значения поля "Общая стоимость" от значения поля "Количество". Значение поля "Общая стоимость" может вычисляться как значение поля "Количество", умноженное на значение поля 'Цена за единицу измерения" из таблицы "Товары" (из записи с таким же Значением поля "Товар"). Поэтому поле "Общая стоимость" из таблицы "Отпуск товаров со склада" удаляем. 46 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений В результате получаем нормализованную базу данных со следующей структурой: 47 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений В таблице "Покупатели" значение поля "Адрес" зависит от значения поля "Город", поскольку в разных городах могут оказаться улицы с одинаковыми названиями и, соответственно, дома с одинаковыми номерами. Думается, что такой зависимостью можно пренебречь, поскольку поле "Адрес" в нашем случае носит чисто информационный характер и не должно входить в условия запросов самостоятельно. Вообще говоря, на практике не всегда возможно получить идеально нормализованную БД. Часто к этому и не стремятся – по причинам, изложенным ниже. Нормализация таблиц БД призвана устранить из них избыточную информацию. Как видно из приведенных выше примеров, таблицы нормализованной БД содержат только один элемент избыточных данных – это поля связи, присутствующие одновременно у родительской и дочерних таблиц. Поскольку избыточные данные в таблицах не хранятся, экономится дисковое пространство. 48 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Однако, у нормализованной БД есть и недостатки, прежде всего практического характера. Чем шире число сущностей, охватываемых предметной областью, тем из большего числа таблиц будет состоять нормализованная БД. Базы данных в составе больших систем, управляющих жизнедеятельностью крупных организаций и предприятий, могут содержать сотни связанных между собою таблиц. Поскольку порог человеческого восприятия не позволяет одновременно воспринимать большое число объектов с учетом их взаимосвязей, можно утверждать, что с увеличением числа нормализованных таблиц уменьшается целостное восприятие базы данных как системы взаимосвязанных данных. Поэтому при разработке и эксплуатации крупных систем нередки ситуации, когда каждый сотрудник представляет себе процессы, протекающие только в части системы. Известны случаи эволюционного создания таких систем, принципы функционирования которых впоследствии признавались вышедшими за границы понимания. 49 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Другим недостатком нормализованной БД является необходимость считывать из таблиц связанные данные при выполнении запросов к нескольким таблицам БД. Так, например, пусть для рассмотренной выше БД, содержащей сведения о расходе товара со склада, требуется выдать отчет, в котором для каждой накладной указан покупатель и его реквизиты (город и адрес). Для этого необходимо каждую запись в таблице "Накладные" объединить по названию покупателя (поле связи) с соответствующей записью из таблицы "Покупатели". Операции такого объединения подразумевают поиск и позиционирование в таблице "Покупатели" и могут выполняться достаточно медленно, особенно когда одна из таблиц имеет большой объем, данные в базе данных и на диске фрагментированы, и т. д. 50 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 5. Нормализация отношений Замечено, что ненормализованные (скажем так: "не вполне нормализованные") данные отыскиваются быстрее, если они хранятся в одной таблице, по сравнению со случаем поиска данных в одной или более связанных таблиц. Подобное ускорение тем заметнее, чем больше число записей в связанных таблицах. На скорость поиска в подчиненной таблице могут оказывать негативное влияние такие факторы, как слишком большое число вложенных полей в индексе; индекс, структура которого не совсем корректно определена, и другие факторы. Приведенные выше соображения не следует воспринимать как призыв вовсе не нормализовывать данные. Эти соображения лишь призваны показать, что при работе с данными большого объема приходится искать компромисс между требованиями нормализации (то есть "логичности" данных и экономии места на носителях информации) и необходимостью улучшения быстродействия системы. 51 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 6. Сравнение моделей баз данных При сравнении моделей данных очень трудно отделить факторы, характеризующие принципиальные особенности модели, от факторов, связанных с реализацией этих моделей данных средствами конкретных СУБД. Рассматривая преимущества и недостатки известных моделей данных, следует отметить ряд несомненных достоинств реляционного подхода: ü Простота. В реляционной модели всего одна информационная конструкция, которая формализует табличное представление данных, привычное для пользователей экономистов. ü Теоретическое обоснование. Наличие теоретически обоснованных методов нормализации отношений и проверки ацикличности структуры позволяет получать базы данных с заданными характеристиками. ü Независимость данных. Когда необходимо изменить структуру реляционной БД, это, как правило, приводит к минимальным изменениям в прикладных программах. 52 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 6. Сравнение моделей баз данных Среди недостатков реляционной модели данных необходимо назвать следующие: ü Низкая скорость при выполнении операции соединения. ü Большой расход памяти для представления реляционной БД. Хотя проектирование в ЗНФ рассчитано на минимальную избыточность (каждый факт представляется в БД один раз), другие модели данных обеспечивают меньший расход памяти для представления тех же фактов. Например, длина адреса связи обычно намного меньше, чем длина значения атрибута. 53 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 6. Сравнение моделей баз данных Достоинствами иерархической модели данных являются следующие: ü Простота. Хотя модель использует три информационные конструкции, иерархический принцип соподчиненности понятий является естественным для многих экономических задач (например, организация статистической отчетности). ü Минимальный расход памяти. Для задач, допускающих реализацию с помощью любой из трех моделей данных, иерархическая модель позволяет получить представление с минимально требуемой памятью. Недостатки иерархической модели: ü Неуниверсальность. Многие важные варианты взаимосвязи данных невозможно реализовать средствами иерархической модели, или реализация связана с повышением избыточности в базе данных. ü Допустимость только навигационного принципа доступа к данным. ü Доступ к данным производится только через корневое отношение. 54 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 6. Сравнение моделей баз данных Необходимо отметить следующие преимущества сетевой модели данных: ü Универсальность. Выразительные возможности сетевой модели данных являются наиболее обширными в сравнении с остальными моделями. ü Возможность доступа к данным через значения нескольких отношений (например, через любые основные отношения). В качестве недостатков сетевой модели данных можно назвать: ü Сложность, т. е. обилие понятий, вариантов их взаимосвязей и особенностей реализации. ü Допустимость только навигационного принципа доступа к данным. 55 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 6. Сравнение моделей баз данных Реляционные БД в 70 х годах XX века практически вытеснили БД других видов из за сложности представления данных в иерархической и сетевой моделях и необходимости определения связей между данными на этапе проектирования БД, в то время как в реляционных БД связи между таблицами могут устанавливаться непосредственно в момент выполнения запросов. Кроме того, разработчикам и пользователям значительно проще отображать сущности предметной области в табличных структурах данных. Однако иерархический и сетевой подходы продолжают жить, они находят свое воплощение в отдельных специализированных БД и являются основой построения архитектуры так называемых "пост реляционных" баз данных. Быстрыми темпами развиваются объектно ориентированные БД, оперирующие категориями объектов, и так называемые полнотекстовые БД, позволяющие производить быстрые выборки из неструктурированной информации (например, текстов, изображений и т. д. ). Однако и в настоящее время реляционные БД остаются наиболее используемыми. 56 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 7. Организация баз данных По технологии обработки данных базы данных подразделяются на централизованные и распределенные. Централизованная база данных хранится в памяти одной вычислительной системы. Если эта вычислительная система является компонентом сети ЭВМ, возможен распределенный доступ к такой базе. Такой способ использования баз данных часто применяют в локальных сетях ПК. Распределенная база данных состоит из нескольких, возможно пересекающихся или даже дублирующих друга частей, хранимых в различных ЭВМ вычислительной сети. Работа с такой базой осуществляется с помощью системы управления распределенной базой данных. По способу доступа к данным базы данных разделяются на базы данных с локальным доступом и базы данных с удаленным (сетевым доступом). 57 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 7. Организация баз данных Системы централизованных баз данных с сетевым доступом предполагают различные архитектуры подобных систем: файл сервер и клиент сервер. Не зависимо от структуры ИС, технических и программных средств, каждая ИС имеет определенную архитектуру, которая в свою очередь влияет на ИС. Виды архитектур ИС: ü централизованная обработка данных; ü архитектура "файл сервер"; ü архитектура "клиент сервер". 58 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 7. 1. Централизованная обработка данных Особенность централизованной обработки данных на локальном компьютере заключается в том, что на одном компьютере функционируют: ü программные средства пользовательского интерфейса, обеспечивающие интерактивный режим работы пользователя; ü программные средства приложений, выполняющие содержательную обработку данных; ü БД. Развитие ИС с централизованной обработкой данных ограничено: ü производительностью центрального компьютера, влияющей на своевременность обработки всех приложений; ü техническими параметрами центрального компьютера: объемом оперативной памяти и объемом дисковой памяти для БД; ü надежностью работы компьютера и программного обеспечения. 59 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 7. 1. Централизованная обработка данных 60 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 7. 2. Архитектура "файл-сервер" Архитектура систем БД с сетевым доступом предполагает выделение одного из компьютеров сети в качестве главного, который называется файловым сервером (файл-сервер). На такой машине хранятся совместно используемые файлы и централизованная БД. Емкость дисковой памяти такого сервера больше, чем на обычном компьютере. Файловый сервер используется при этом только как хранилище, а собственно обработка осуществляется на компьютере пользователя. Все другие компьютеры сети выполняют функции рабочих станций, с помощью которых поддерживается доступ пользовательской системы к централизованной базе данных. Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где в основном и производится обработка. 61 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 7. 2. Архитектура "файл-сервер" При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает. Пользователи могут создавать также на рабочих станциях локальные БД, которые используются ими монопольно. В сети может быть несколько файло вых серверов в зависимости от объема решаемых задач. Помимо фай лов, сервер может предоставлять в совместное пользование и другие виды своих ресурсов: принтер, модем и др. Концепция файл сервер условно может быть отображена следующим образом: 62 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 7. 3. Архитектура "клиент-сервер" В концепции клиент сервер подразумевается, что, помимо хранения централизованной базы данных, главный компьютер (сервер базы данных) должен обеспечивать выполнение основного объема обработки данных. Программные системы архитектуры "клиент сервер" состоят из двух частей: ПО сервера и ПО пользователя клиента. Рабо та этих систем организуется следующим образом. Программы клиен ты выполняются на компьютере пользователя и формируют запрос, посылаемый к программе серверу, которая работает на компьютере общего доступа. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Основная обработка данных производится мощным сервером, а на компьютер пользователя посылаются только результа ты выполнения запроса. Извлеченные данные (но не файлы) транспортируются по сети от сервера к клиенту. 63 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 7. 2. Архитектура "файл-сервер" Спецификой архитектуры клиент сервер является использование языка запросов SQL. Сервер баз данных используется в мощных СУБД, таких как Microsoft SQL Server, Oracle и др. , работающих с распределенными БД. Концепция клиент сервер условно может быть изображена следующим образом: 64 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 7. 3. Архитектура "клиент-сервер" Серверы БД рассчитаны на работу с большими объемами данных (десятки гигабайт и более) и значительным числом пользователей, обеспечивая при этом высокую производительность, надежность и защищенность. В приложениях глобальных сетей архитектура "клиент сервер" (в определенном смысле) является основной. При переходе на многопользовательский доступ к данным такая архитектура обеспечивает: ü сохранение информации при аппаратных средствах; ü защиту данных от несанкционированного доступа; ü непротиворечивый доступ одновременно нескольких пользователей к одним и тем же данным. 65 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 7. 3. Архитектура "клиент-сервер" Преимущества архитектуры "клиент сервер" по сравнению с системами, имеющими центральный процессор и терминалы (архитектура "файл сервер"), заключаются в следующем: ü не требуются единовременные крупные финансовые затраты. Мощность системы клиент сервер можно наращивать постепенно; ü увеличение количества терминалов в системе с центральным процессором не приводит к наращиванию ее вычислительной мощности, а только повышает рабочую нагрузку. В системах типа клиент сервер добавление нового сервера или рабочей стан ции, напротив, повышает общую вычислительную мощность системы. Это приводит к распределению ресурсов и собственно система не перегружается и не истощается; ü любые изменения, связанные с увеличением мощности систе мы (приобретение дополнительных технических и программ ных редств) с с центральным процессором требуют дополни тельных затрат, превышающих аналогичные затраты для систе мы "клиент сервер"; 66 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 7. 3. Архитектура "клиент-сервер" ü пользователь в системах "клиент сервер" имеет большую свободу в выборе среды, рабочей платформы для запуска приложений; ü технология клиент сервер имеет большую гибкость и производительность при построении многоуровневых информационных систем. Одной из самых ответственных задач при эксплуатации информационных систем является обеспечение целостности данных, поскольку даже в самой надежной из них существует риск потери информации, жизненно важной для фирмы. Поэтому необходимо иметь механизм для быстрого восстановления потерянных данных. Это может быть обеспечено построением развитой системы резервного копирования, периодически создающей копии информации с целью ее последующего восстановления в случае частичного или полного разрушения. Кроме того, такая система может собирать и обслуживать архив корпоративных данных. 67 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 7. 3. Архитектура "клиент-сервер" Преимуществами технологии "клиент сервер" при реализации системы сетевого резервного копирования являются: ü возможность использования одного устройства для хранения резервных копий с различных узлов сети; ü централизованное планирование работ и управление ими; ü локализация хранения резервных копий. В общем случае технология клиент сервер подразумевает распределение обработки данных между узлами сети. Поэтому ее целесообразно использовать при построении систем резервного копирования для сохранения данных, распределенных в сети. При построении больших ИС актуальна проблема создания распределенных систем обработки данных на основе интеграции неоднородных аппаратно программных платформ. 68 Лекция № 6 (03. 10. 2013)
Программное обеспечение маркетинговых исследований 7. 3. Архитектура "клиент-сервер" Многоуровневая архитектура ИС обеспечивает изоляцию параллельно работающих процессов, в результате ошибки в работе одной программы не влияют на работу других программ либо операционной системы. Для БД осуществляется администрирование, регистрация каждого имевшего место доступа к базе данных и выполненных изменений в специальном журнале БД. Недостатком архитектуры "клиент сервер" является наличие очень высоких требований к техническому комплексу сервера БД, который становится центральным звеном всей ИС и определяет ее надежность. 69 Лекция № 6 (03. 10. 2013)
Скачать презентацию Программное обеспечение маркетинговых исследований Системы управления базами данных
Lection #5.ppt